navegando o pci dss...de cartão. o ambiente de dados do portador de cartão é aquela parte da rede...

Payment Card Industry (PCI) Indústria de Cartões de Pagamento (PCI) Padrão de Segurança de Dados

Navegando o PCI DSS

Entendendo as Razões das Exigências Versão 1.1

Fevereiro de 2008

Navegando o PCI DSS: Entendendo a Razão das Exigências, v 1.1 Fevereiro de 2008 Copyright 2008 PCI Security Standards Council LLC Página i

Índice

Introdução ............................................................................................................................................................................ ii Dados do Portador de Cartão e Elementos do Dado Confidencial de Autenticação ................................................... iii

Localização dos Dados do Portador de Cartão e Dado Confidencial de Autenticação .......................................................................................... iv Dado da Trilha 1 vs. Trilha 2 ................................................................................................................................................................................... v

Diretrizes para as Exigências 1 e 2: Construir e Manter uma Rede Segura ................................................................................. 3 Exigência 1: Instalar e manter uma configuração de firewall para proteger os dados do portador de cartão ........................................................ 3 Exigência 2: Não usar as senhas padrões de sistema e parâmetros de segurança fornecidos pelos prestadores de serviços ........................... 8

Diretrizes para as Exigências 3 e 4: Proteger os Dados Armazenados do Portador de Cartão ............................................... 11 Exigência 3: Proteger os Dados Armazenados do Portador de Cartão ................................................................................................................ 11 Exigência 4: Codificar a transmissão dos dados do portador de cartão que transitam nas redes públicas abertas ............................................ 17

Diretrizes para as Exigências 5 e 6: Manter um Programa de Administração da Vulnerabilidade ........................................... 19 Exigência 5: Usar e atualizar regularmente os softwares ou programas antivírus ............................................................................................... 19 Exigência 6: Desenvolver e manter seguros os sistemas e aplicativos ................................................................................................................ 20

Diretrizes para as Exigências 7, 8 e 9: Implementar Medidas Rígidas de Controle ao Acesso ................................................ 25 Exigência 7: Restringir o acesso aos dados do portador de cartão a apenas aqueles que necessitam conhecê-los para a execução dos trabalhos ................................................................................................................................................................................................................ 25 Exigência 8: Atribuir um ID único para cada pessoa que possua acesso ao computador ................................................................................... 26 Exigência 9: Restringir ao máximo o acesso físico aos dados do portador de cartão .......................................................................................... 30

Diretrizes para as Exigências 10 e 11: Acompanhar e Testar Regularmente as Redes ............................................................ 34 Exigência 10: Acompanhar e monitorar todo o acesso aos recursos da rede e dados do portador de cartão .................................................... 34 Exigência 11: Testar regularmente os sistemas e os processos de segurança ................................................................................................... 38

Diretrizes para a Exigência 12: Manter uma Política de Segurança da Informação ................................................................... 41 Exigência 12: Manter uma política que atenda à segurança da informação para funcionários e prestadores de serviços ................................. 41

Diretrizes para a Exigência A.1: Aplicação do PCI DSS aos Prestadores de Serviço de Host ................................................. 47 Anexo A: Padrão de Segurança de Dados PCI: Documentos Relacionados .............................................................................. 49

Navegando o PCI DSS: Entendendo a Razão das Exigências, v 1.1 Fevereiro de 2008 Copyright 2008 PCI Security Standards Council LLC Página ii

Introdução Este documento descreve as 12 exigências do Padrão de Segurança de Dados da Indústria de Cartões de Pagamento PCI (Payment Card Industry Data Security Standard - PCI DSS, em inglês), em conjunto com as diretrizes para explicar as razões de cada exigência. Este documento tem como objetivo auxiliar os estabelecimentos, prestadores de serviços e instituições financeiras que podem desejar ter um claro entendimento a respeito do Padrão de Segurança de Dados da Indústria de Cartões de Pagamento, o significado específico e intenção por trás das exigências detalhadas para tornar seguros os componentes do sistema (servidores, rede, aplicativos, etc.) que dão suporte ao ambiente de dados do portador de cartões. NOTA: “Navegando o PCI DSS: Entendendo a Razão das Exigências” deve ser considerado apenas como uma diretriz. Ao preencher o Questionário de Avaliação on-site do PCI DSS ou o Questionário de Auto-avaliação (SAQ), os documentos a serem considerados são o PCI DSS v 1.1, os Procedimentos de Auditoria de Segurança do PCI DSS e os Questionários de Auto-avaliação do PCI DSS v 1.1. As Exigências do PCI DSS se aplicam a todos os componentes do sistema que estão incluídos ou conectados ao ambiente de dados do portador de cartão. O ambiente de dados do portador de cartão é aquela parte da rede que possui os dados do usuário ou os dados confidenciais de autenticação, incluindo os componentes de rede, servidores e aplicativos.

Os componentes de rede podem incluir, mas não estão limitados a firewalls, switches, routers, pontos de acesso de wireless, dispositivos de rede e outros dispositivos de segurança.

Os tipos de servidor podem incluir, mas não estão limitados ao seguinte: web, banco de dados, autenticação, mail, proxy, network time protocol (NTP) e domain name server (DNS).

Os aplicativos podem incluir, mas não estão limitados a todos os programas customizados ou adquiridos, incluindo os aplicativos internos e externos (Internet).

A segmentação adequada da rede, a qual isola os sistemas que armazenam, processam ou transmitem os dados do portador de cartão daqueles que não o fazem, pode reduzir o escopo do ambiente de dados do portador de cartão. Um Assessor de Segurança Qualificado (Qualified Security Assessor - QSA) pode ajudar na determinação do escopo dentro do ambiente de dados do portador de cartão da organização, além de oferecer ajuda sobre como diminuir o escopo de um levantamento de PCI DSS através da implementação apropriada da segmentação de rede. Para a questão com relação a se uma implementação específica é ou não consistente com os padrões ou encontra-se em “conformidade” com uma exigência específica, o PCI SSC recomenda que as organizações consultem um Assessor de Segurança Qualificado (QSA) ou façam a validação da sua implementação de tecnologia, processos e conformidade com o Padrão de Segurança de Dados PCI. A capacitação de um QSA para trabalhar com ambientes de rede complexos colabora para implementar as melhores práticas e diretrizes para o estabelecimento ou prestador de serviço que deseja estar em conformidade. A Lista de Assessores de Segurança Qualificados do PCI SSC pode ser encontrada no: https://www.pcisecuritysteards.org/pdfs/pci_qsa_list.pdf

Navegando o PCI DSS: Entendendo a Razão das Exigências, v 1.1 Fevereiro de 2008 Copyright 2008 PCI Security Standards Council LLC Página iii

Dados do Portador de Cartão e Elementos do Dado Confidencial de Autenticação A tabela a seguir mostra os elementos de dados do portador de cartão e dado confidencial de autenticação comumente utilizados, sejam eles os dados cujo armazenamento é permitido ou proibido, ou se cada elemento do dado deve ser protegido. Esta tabela não tem o objetivo de ser completa; seu único propósito é ilustrar os diferentes tipos de exigências que se aplicam a cada elemento do dado. Os dados do portador de cartão são definidos como o Número de Conta Primária (Primary Account Number – PAN, ou número do cartão de crédito) e outro dado obtido como parte de uma transação de pagamento, incluindo os seguintes elementos de dados (ver maiores detalhes abaixo na tabela):

PAN Nome do portador de cartão Data do vencimento Código de serviço Dado confidencial de autenticação (1) dado completo da tarja magnética; 2) CAV2 / CVC2 / CVV2 / CID e 3) PINs / blocos de PIN)

O Número de Conta Primária (PAN) é o fator de definição sobre a aplicabilidade das Exigências do PCI DSS e PA-DSS. Se o PAN não for armazenado, processado ou transmitido, o PCI DSS e PA-DSS não se aplicam.

Elemento de Dado

Armazenagem Permitida

Proteção Exigida

Exigência do PCI DSS 3 e 4

Dados do Portador de Cartão

Número de Conta Primária Sim Sim Sim

Nome do portador de cartão 1 Sim Sim 1 Não

Código de serviço 1 Sim Sim 1 Não

Data do vencimento 1 Sim Sim 1 Não

Dado Confidencial de Autenticação 2

Tarja magnética completa 1 Não N/A N/A

CAV2/CVC2/CVV2/CID Não N/A N/A

PIN/Bloco de PIN Não N/A N/A

1 Estes elementos de dados devem ser protegidos se armazenados em conjunto com o PAN. Esta proteção deve estar de acordo com as Exigências do PCI DSS para a proteção

geral do ambiente do portador de cartão. Adicionalmente, outra legislação (ex: relacionada com a proteção do dado pessoal do consumidor, privacidade, roubo de identidade ou segurança de dado) pode exigir uma proteção específica deste dado, ou a devida divulgação das práticas de uma organização sobre se os dados pessoais do consumidor estão sendo coletados durante o curso do negócio. O PCI DSS, entretanto, não se aplica aos PANs que não são armazenados, processados ou transmitidos.

2 Não armazenar o dado confidencial de autenticação após a autorização (mesmo se codificado).

Navegando o PCI DSS: Entendendo a Razão das Exigências, v 1.1 Fevereiro de 2008 Copyright 2008 PCI Security Standards Council LLC Página iv

Localização dos Dados do Portador de Cartão e Dado Confidencial de Autenticação O dado confidencial de autenticação é composto pelo dado da tarja magnética (ou trilha) 3, código ou valor de validação do cartão 4 e dado do PIN 5. O armazenamento do dado confidencial de autenticação é proibido! Este dado é muito valioso para os hackers na medida em que permite que eles criem cartões de pagamento falsificados bem como transações fraudulentas. Consultar o Glossário do PCI DSS, Abreviações e Acrônimos para ter uma definição completa do “dado confidencial de autenticação.” O desenho da frente e verso de um cartão de crédito abaixo, mostra a localização dos dados do portador de cartão e dado confidencial de autenticação.

3 Dado codificado na tarja magnética usado para a autorização durante uma transação com cartão presente. As organizações não podem reter os dados completos da tarja

magnética após a autorização de uma transação. Os únicos elementos do dado da trilha que podem ser retidos são o número da conta, data do vencimento e o nome. 4 Valor de três ou quatro dígitos impresso sobre ou ao lado do painel de assinatura ou na face de um cartão de pagamento que é usado para verificação em transações de cartão

ausentes. 5 Número de Identificação Pessoal digitado pelo portador de cartão durante uma transação com cartão presente e/ou bloco de PIN codificado presente na mensagem da transação.

Navegando o PCI DSS: Entendendo a Razão das Exigências, v 1.1 Fevereiro de 2008 Copyright 2008 PCI Security Standards Council LLC Página v

Dado da Trilha 1 vs. Trilha 2 Se o dado completo da trilha (tanto trilha 1 como trilha 2) for armazenado, os hackers que obtiverem o dado poderão reproduzir e vender cartões de pagamento ao redor do mundo. O armazenamento do dado completo da trilha também se constitui em uma violação dos regulamentos operacionais das marcas de pagamento e pode gerar penalidades e multas. A ilustração abaixo oferece informações sobre o dado da Trilha 1 e Trilha 2, descrevendo as diferenças e mostrando o layout do dado conforme armazenado na tarja magnética.

Trilha 1 Trilha 2

Contém todos os campos de ambas as trilha 1 e trilha 2 Comprimento de até 79 caracteres

Tempo de processamento curto para as transmissões dial-up antigas

Comprimento de até 40 caracteres

Navegando o PCI DSS: Entendendo a Razão das Exigências, v 1.1 Fevereiro de 2008 Copyright 2008 PCI Security Standards Council LLC Página 1

Diretrizes Relacionadas com o Padrão de Segurança de Dados PCI Construir e Manter uma Rede Segura

Exigência 1: Instalar e manter uma configuração de firewall para proteger os dados do portador de cartão Exigência 2: Não usar as senhas padrões de sistema e outros parâmetros de segurança fornecidos pelos prestadores

de serviços

Proteger os Dados do Portador de Cartão

Exigência 3: Proteger os dados armazenados do portador de cartão Exigência 4: Codificar a transmissão dos dados do portador de cartão que transitam nas redes públicas abertas

Manter um Programa de Administração da Vulnerabilidade

Exigência 5: Usar e atualizar regularmente o software antivírus Exigência 6: Desenvolver e mantenha seguros os sistemas e aplicativos

Implementar Medidas Rígidas de Controle ao Acesso

Exigência 7: Restringir o acesso aos dados do portador de cartão apenas àqueles que necessitem conhecê-los para a execução dos trabalhos

Exigência 8: Atribuir um ID único para cada pessoa que possua acesso ao computador Exigência 9: Restringir ao máximo o acesso físico aos dados do portador de cartão

Acompanhar e Testar Regularmente as Redes

Exigência 10: Acompanhar e monitorar todo o acesso aos recursos da rede e dados do portador de cartão


Exigência 11: Testar regularmente os sistemas e processos de segurança

Manter uma Política de Segurança da Informação

Exigência 12: Manter uma política que atenda à segurança da informação


Diretrizes para as Exigências 1 e 2: Construir e Manter uma Rede Segura

Exigência 1: Instalar e manter uma configuração de firewall para proteger os dados do portador de cartão Os firewalls são dispositivos que controlaram o tráfego interno e externo via computador, admitido na rede da empresa, bem como o tráfego em áreas mais críticas dentro da rede interna da empresa. Um firewall examina todo o tráfego da rede e bloqueia aquelas transmissões que não atendem aos critérios específicos de segurança.

Todos os sistemas devem ser protegidos contra o acesso não autorizado através da Internet, quer entrando via e-commerce, acesso dos funcionários com base na Internet e via desktop browsers, ou acesso via e-mail de funcionários. Geralmente, os caminhos aparentemente insignificantes para entrar e sair da Internet podem propiciar um acesso desprotegido a sistemas importantes. O firewall é o principal mecanismo de proteção de qualquer rede de computador.

Exigência Diretriz

1.4.1 Estabelecer um padrão de configuração de firewall que inclua o seguinte:

Firewalls são dispositivos de software ou hardware que bloqueiam uma penetração indesejada na rede. Sem a implantação de políticas e procedimentos para documentar como os funcionários devem configurar os firewalls, uma organização pode perder facilmente a sua primeira linha de defesa para a proteção de dados.

1.1.1 Um processo formal de aprovação e teste de todas as conexões externas e mudanças na configuração do firewall.

Uma política e processo para a aprovação e teste de todas as conexões e mudanças no firewall irão ajudar a prevenir problemas de segurança causados pela configuração inadequada da rede ou firewall.

1.1.2 Um diagrama atualizado da rede com todas as conexões que levem aos dados do portador de cartão, incluindo qualquer rede wireless.

Os diagramas de rede permitem que a organização identifique a localização de todos os seus dispositivos de rede. Sem um diagrama de rede, algum dispositivo pode ser ignorado e tornar-se desprotegido e, portanto, vulnerável ao comprometimento.

1.1.3 Exigências para um firewall em cada conexão com a Internet e entre qualquer zona desmilitarizada (DMZ) e a zona interna da rede.

O uso de um firewall em cada conexão de entrada (e saída) da rede permite à organização monitorar e controlar o acesso de entrada e saída e minimizar as chances de um hacker obter um acesso à área interna da rede.

1.1.4 Descrição dos grupos, tarefas e responsabilidades para a administração lógica dos componentes da rede.

Esta descrição das funções e delegação de responsabilidades assegura que alguém é claramente responsável pela segurança de todos os componentes e está ciente desta responsabilidade e que nenhum dispositivo se encontra sem gerenciamento.


Exigência Diretriz

1.1.5 Lista documentada dos serviços e ports necessários para o negócio.

Os comprometimentos geralmente ocorrem em função de serviços e ports não usados e/ou inseguros, visto que estes usualmente possuem vulnerabilidades conhecidas e muitas organizações não aplicam os patchs de segurança para estes serviços e ports que não usam (muito embora as vulnerabilidades estejam presentes). Cada organização deve claramente decidir quais serviços e ports são necessários para as suas atividades, documentá-los e assegurar que os demais sejam neutralizados ou removidos. As organizações devem também considerar o bloqueio de todo o tráfego e apenas reabrir estes ports uma vez que determinada necessidade tenha sido identificada e documentada.

1.1.6 Justificativa e documentação de qualquer outro protocolo disponível além do hypertext transfer protocol (HTTP), secure sockets layer (SSL), secure shell (SSH) e virtual private network (VPN).

1.1.7 Justificativa e documentação de qualquer protocolo de risco permitido (por exemplo, protocolo de transferência de arquivo (FTP), que inclua a razão para o uso do protocolo e características de segurança implementadas.

Existem muitos protocolos necessários às atividades de uma organização (ou foram habilitados na ocasião da instalação) e que são comumente usados por hackers para o comprometimento da rede. Além da explicação dada na exigência 1.1.5, se estes protocolos são necessários para o negócio, os mesmos devem ser claramente entendidos e aceitos pela organização, seu uso justificado e as características de segurança que permitem que os mesmos possam ser usados devem ser documentadas e implementadas.

1.1.8 Revisão trimestral dos conjuntos de regras para o firewall e router.

Esta revisão proporciona à organização uma oportunidade trimestral de eliminar quaisquer regras desnecessárias, ultrapassadas ou incorretas e assegura que qualquer conjunto de regras permita apenas os serviços autorizados e ports que atendam a esta justificativa de negócio.

1.1.9 Padrões de configuração para os routers. Estes dispositivos, junto com os firewalls, fazem parte da arquitetura que controla os pontos de entrada na rede. Políticas documentadas ajudam os funcionários a configurar e tornar seguros os routers e assegurar que a primeira linha de defesa da organização para a proteção dos dados permanece robusta.

1.4.1 Construir uma configuração de firewall que não permita qualquer tráfego proveniente das redes e hosts, “não confiáveis”, com exceção dos protocolos necessários ao ambiente de dados do portador de cartão.

Se um firewall encontra-se instalado, mas não possui as regras para controlar ou limitar determinados tráfegos, usuários maliciosos podem ser capazes de explorar os protocolos e ports vulneráveis e atacar a sua rede.

1.4.1 Construir uma configuração de firewall que restrinja as conexões entre os servidores de acesso público e qualquer componente do sistema que armazene os dados do portador de cartão, incluindo quaisquer


Exigência Diretriz conexões de redes wireless. Esta configuração de firewall deve incluir o seguinte:

1.3.1 Restrição ao tráfego de entrada da Internet aos endereços do protocolo de internet (IP)

dentro da DMZ (filtros de ingresso).

Normalmente um pacote (packet) contém o endereço de IP do computador que o enviou originalmente. Isto permite que os demais computadores na rede saibam de onde ele veio. Em certos casos, estes endereços de IP enviados podem ser imitados pelos hackers. Por exemplo, um hacker pode enviar um pacote com endereços “spoofed”, de forma a que (a menos que o firewall o proíba) o pacote seja capaz de acessar a sua rede a partir da Internet, parecendo ser interno, e portanto, um tráfego legítimo. Uma vez que o hacker se encontra dentro da sua rede, ele pode começar a comprometer os seus sistemas. O “ingress filtering” é uma técnica que você pode usar em seu firewall para filtrar os pacotes que venham à sua rede para, entre outras coisas, assegurar que os mesmos não são “spoofed” ou que pareçam ter vindo da sua própria rede interna. Para obter maiores informações sobre “packet filtering”, considere buscar informações sobre uma técnica denominada “egress filtering.”

1.3.2 Não permitir que os endereços internos passem da Internet para a DMZ.

1.3.3 Implementação da inspeção “stateful”, também conhecida como “dynamic packet filtering” (isto é, apenas as conexões “estabelecidas” são permitidas na rede).

Um firewall que executa um “stateful packet inspection” mantém o "estado" (ou o status) para cada conexão com o firewall. Ao manter o "estado", o firewall sabe se o que parece ser uma resposta a uma conexão anterior é verdadeiramente uma resposta (visto que ele "lembra" a conexão anterior) ou se é alguém tentando “spoof” ou enganar o firewall para ele permitir a conexão.

1.3.4 Colocação do banco de dados em uma zona interna da rede, separada da DMZ.

A informação da conta de um cartão de pagamento necessita o mais alto nível de proteção. Se a informação da conta esta localizada dentro da DMZ, o acesso a esta informação é fácil de ser alcançada por um atacante externo, visto que são poucas as camadas a serem penetradas. Sem um firewall protegendo a informação da conta, o dado fica vulnerável aos usuários mal intencionados de dentro da rede ou quaisquer hackers externos que sejam capazes de penetrar na mesma.

1.3.5 Restrição do tráfego de entrada e de saída apenas para o que for necessário ao ambiente de cartões de pagamento.

Esta exigência tem o objetivo de evitar que os hackers tenham acesso à rede da organização via endereços de IP não autorizados que usam os serviços, protocolos, ou ports de uma forma não autorizada; (por exemplo, ao enviar o dado que obtiveram de dentro da sua rede para fora em direção a um servidor externo).


Exigência Diretriz

1.3.6 Arquivos seguros e sincronizados de configuração de router. Por exemplo, os arquivos de configuração de execução (para o funcionamento normal dos routers) e arquivos de configuração de partida (quando as máquinas são religadas) devem possuir a mesma configuração segura.

Embora os arquivos de configuração sejam usualmente implementados com parâmetros seguros, o arquivo de start-up (os routers apenas rodam estes arquivos mediante um religamento (re-start)) pode não ser implementado com os mesmos parâmetros seguros porque roda apenas ocasionalmente. Quando um router não é religado com os mesmos parâmetros seguros usados pelos arquivos de configuração, pode ter como resultado regras mais fracas que permitem a penetração do hacker na rede.

1.3.7 Bloqueio de qualquer outro tráfego de entrada e saída que não seja especificamente permitido.

Todos os firewalls devem incluir uma regra que bloqueie todo o tráfego de entrada e saída não especificamente necessário. Isto irá prevenir a criação de espaços que venham permitir um tráfego de entrada e saída não intencional e potencialmente prejudicial.

1.3.8 Instalação de um perímetro de firewalls entre quaisquer redes wireless, o ambiente dos dados do portador de cartão e configuração destes firewalls para bloquear qualquer tráfego do ambiente wireless ou controlar qualquer tráfego (se tal tráfego for necessário para o objetivo do negócio).

A implementação e exploração da tecnologia wireless conhecida (ou desconhecida) dentro da rede é um caminho comum para os usuários mal intencionados obterem acesso à rede e aos dados do portador de cartão. Se um dispositivo wireless ou de rede é instalado sem o conhecimento da organização, um hacker pode penetrar na rede de forma fácil e “invisível”. Se os firewalls não restringirem o acesso das redes wireless no ambiente do cartão de pagamento, os hackers que ganharem o acesso não autorizado à rede wireless podem facilmente se conectar ao ambiente de cartão de pagamento e comprometer a informação da conta.

1.3.9 Instalação de um software de firewall individual em qualquer dispositivo portátil e/ou computador de propriedade do funcionário que possua conexão direta com a Internet (por exemplo, laptops usados pelos funcionários), os quais sejam usados para o acesso à rede da organização.

Se um computador não possui um firewall ou programa antivírus instalado, spywares, Trojans, vírus e worms (malware) podem ser baixados de forma imperceptível. O computador fica ainda mais vulnerável quando conectado diretamente à Internet e não por trás de um firewall corporativo. Um Malware carregado em um computador que não esteja protegido por firewall corporativo pode buscar de forma insidiosa a informação dentro da rede quando o computador for re-conectado à rede corporativa.

1.4 Proibir o acesso público direto entre as redes externas e qualquer componente do sistema de armazenagem dos dados do portador de cartão (por exemplo, banco de dados, registros, trace files).

O objetivo de um firewall é gerenciar e controlar todas as conexões entre os sistemas internos públicos (especialmente aqueles que armazenam os dados do portador de cartão). Se o acesso direto é permitido entre os sistemas públicos e aqueles que armazenam os dados do portador de cartão, a proteção oferecida pelo firewall é evitada e os componentes do sistema que armazenam os dados do portador de cartão podem ser expostos a um comprometimento.

1.4.1 Implementação de uma DMZ para filtrar e O DMZ é a parte do firewall voltada para a Internet pública e gerencia as


Exigência Diretriz verificar todo o tráfego e para bloquear qualquer rota direta para a entrada e saída do tráfego da Internet.

conexões entre a Internet e os serviços internos que uma organização necessita por estar disponível ao público (como um servidor da web). É a primeira linha de defesa para isolar e separar o tráfego necessário para se comunicar com a rede interna daqueles tráfegos que são desnecessários.

1.4.2 Restrição do tráfego de saída dos aplicativos de cartões de pagamento para os endereços de IP dentro da DMZ.

O DMZ também deve avaliar todo o tráfego de saída de dentro da rede para assegurar que o mesmo obedece às regras estabelecidas. Para que o DMZ desempenhe esta função de forma eficiente, não devem ser permitidas as conexões de dentro da rede para quaisquer endereços de fora, a menos que os mesmos tenham a sua legitimidade avaliada pela DMZ.

1.5 Implementar um Internet Protocol (IP) disfarçado, de forma a impedir que os endereços internos sejam traduzidos e revelados na Internet. Use tecnologias que implementem o espaço de endereço RFC 1918, tais como port address translation (PAT) ou network address translation (NAT).

O mascaramento do IP, o qual é administrado pelo firewall, permite que uma organização possua endereços internos que sejam visíveis apenas dentro da rede e endereços externos que são visíveis externamente. Se um firewall não “esconder” ou mascarar os endereços de IP na rede interna, um hacker pode descobrir os endereços internos de IP e tentar ter acesso à rede com endereços de IP “spoofed”.


Exigência 2: Não usar as senhas padrões de sistema e parâmetros de segurança fornecidos pelos prestadores de serviços Os hackers (externos e internos à empresa) geralmente usam as senhas padrão dos prestadores de serviços e outros parâmetros padrões para comprometer os sistemas. Estas senhas e parâmetros são bastante conhecidos nas comunidades de hackers e facilmente obtidos através de informações públicas.

Exigência Diretriz

2.1 Trocar sempre os padrões/configurações estabelecidos pelo prestador de serviço antes da instalação de um sistema na rede (por exemplo, incluir senhas, simple network management protocol (SNMP) community strings e eliminação de contas desnecessárias).

Hackers (externos e internos à organização) geralmente usam a configuração padrão do fornecedor, nomes de contas e senhas para o comprometimento dos sistemas. Estas configurações são muito bem conhecidas nas comunidades de hackers e tornam seu sistema altamente vulnerável ao ataque.

2.1.1 Nos ambientes wireless, mudar os padrões/configurações de wireless do prestador de serviço, incluindo, mas não limitado a, chaves WEP, identificador de conjunto de serviços (service set identifier - SSID) padrão, senhas, SNMP community strings e desativação da transmissão de SSID. Ativar a tecnologia de Wi-Fi Protected Acess (WPA e WPA2) para a codificação e autenticação quando for capacitado a operar a I.

Muitos usuários instalam estes dispositivos sem a aprovação da administração e não mudam as configurações padrões ou mudam os parâmetros de segurança. Se as redes wireless não forem implementadas com parâmetros suficientemente seguros (incluindo a mudança da configuração padrão), farejadores wireless (wireless sniffers) podem espionar o tráfego, facilmente capturar os dados e senhas e perpetrar um ataque à sua rede. Adicionalmente, o key exchange protocol para a antiga versão da criptografia 802.11x (WEP) foi quebrado e pode tornar inútil a codificação.

2.2 Desenvolver uma configuração padrão para todos os componentes do sistema. Certifique-se de que estes padrões atendam a todas as vulnerabilidades de segurança conhecidas e sejam consistentes com os padrões rigorosos de sistema aceitos pela indústria, como por exemplo, através do SysAdmin Audit Network Security Network (SANS), National Institute of Standards Technology (NIST), e Center for Internet Security (CIS).

Existem debilidades conhecidas em muitos sistemas operacionais, bancos de dados e aplicativos empresariais e existem também formas conhecidas de configurar estes sistemas ao reparar as vulnerabilidades de segurança. Para ajudar àqueles que não são especialistas em segurança, organizações de segurança estabeleceram recomendações para fortalecer o sistema, as quais orientam como corrigir estas fraquezas. Se os sistemas forem deixados com estas vulnerabilidades — por exemplo, parâmetros fracos de arquivos ou serviços e protocolos padrões (para os serviços e protocolos que geralmente não são necessários) — um atacante será capaz de usar múltiplos meios conhecidos para atacar os serviços e protocolos vulneráveis e, desta forma, ter acesso à rede da sua organização.


Exigência Diretriz

2.2.1 Implementar apenas uma função principal por servidor (ex: servidores da web, servidores de banco de dados e DNS devem ser implementados em servidores separados).

Isto tem o objetivo de assegurar que os padrões de configuração de sistema da sua organização e processos relacionados atendam às funções do servidor que necessitam possuir um nível de segurança diferente, ou que podem introduzir vulnerabilidades de segurança a outras funções no mesmo servidor. Por exemplo: 1. Um banco de dados, o qual necessita possuir fortes medidas de segurança

instaladas, estaria em risco ao compartilhar um servidor com o aplicativo da web, a qual necessita ser aberta e estar voltada para a Internet.

2. O fato de não aplicar um patch ao que parece ser uma função sem importância, pode resultar em um comprometimento que cause impacto em outras funções mais importantes (tais como banco de dados) no mesmo servidor.

Esta exigência é direcionada aos servidores (usualmente baseados em Unix, Linux ou Windows), mas não aos sistemas de mainframe.

2.2.2 Desativar todos os serviços e protocolos não seguros e desnecessários (serviços e protocolos não diretamente necessários para executar a função específica do dispositivo).

Conforme explicado em 1.1.7, existem muitos protocolos que são necessários a um negócio (ou foram habilitados na instalação) que são comumente usados pelos hackers para o comprometimento da rede. Ao assegurar que estes serviços e protocolos se encontrem sempre desativados quando novos servidores forem instalados, esta exigência deve ser parte do padrão de configuração e processos relacionados da sua organização.

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

Isto tem o objetivo de assegurar que a configuração padrão e processos relacionados da sua organização atendam especificamente aos parâmetros de segurança que possuam implicações de risco conhecidas.

2.2.4 Remover todas as funcionalidades desnecessárias, tais como scripts, drivers, características, subsistemas, sistemas de arquivo (ex: servidores de web desnecessários).

Os padrões de fortalecimento da configuração do servidor devem incluir processos que atendam à questão das funcionalidades desnecessárias que possuem implicações de segurança específicas (como a remoção / desativação de FTP ou do servidor de web se o mesmo não estiver executando estas funções).

2.3 Codificar todo o acesso administrativo que não for via teclado. Use tecnologias tais como SSH, VPN, ou SSL/TLS para a administração baseada na web ou outro acesso administrativo via unidade de teclado.

Se a administração remota não for feita com autenticação de segurança e comunicações codificadas, informações administrativas confidenciais ou de nível operacional (como senhas de administração) podem ser reveladas a um “eavesdropper”. Um hacker pode então usar esta informação para ter acesso à rede, tornar-se um administrador e roubar os dados.


Exigência Diretriz

2.4 Os provedores de serviço de host devem proteger o ambiente e os dados de cada entidade a qual estejam prestando serviço. Estes provedores devem atender a exigências específicas como o especificado na Diretriz para a “Exigência A.1: Aplicação do PCI DSS aos Prestadores de Serviço de Host”.

Isto diz respeito aos prestadores de serviço de host que oferecem ambientes de hosting compartilhados para múltiplos clientes no mesmo servidor. Quando todos os dados se encontram no mesmo servidor e sob o controle de um único ambiente, geralmente seus parâmetros não podem ser gerenciados por um cliente individual e permite que um cliente adicione funções e scripts não seguros que impactam a segurança do ambiente de todos os outros clientes; tornando fácil para um hacker comprometer o dado de um cliente, obtendo acesso aos dados de todos os demais. Consultar também as Diretrizes neste documento na “Diretrizes para a Exigência A.1”.


Diretrizes para as Exigências 3 e 4: Proteger os Dados Armazenados do Portador de Cartão

Exigência 3: Proteger os Dados Armazenados do Portador de Cartão A codificação é um componente crítico da proteção dos dados do portador de cartão. Se um intruso conseguir evitar os controles de segurança da rede e obtiver o acesso aos dados cifrados, sem possuir as chaves adequadas de codificação, os dados não poderão ser lidos ou usados por essa pessoa. Outros métodos efetivos de proteção para os dados armazenados deverão ser considerados como oportunidades potenciais para a diminuição do risco. Por exemplo, não armazenar os dados a menos que seja absolutamente necessário, truncando os dados do portador de cartão se o número completo do PAN não for preciso e não enviar o PAN em e-mails não codificados, são formas de minimizar o risco.

Exigência Diretriz

3.1 Manter os dados armazenados do portador de cartão em um tamanho mínimo. Desenvolver uma política de retenção e destruição de dados. Limitar o tempo e a quantidade de dados retidos exclusivamente para o que é necessário ao negócio e com propósitos legais e/ou regulamentares, conforme documentado no regulamento de retenção de dados.

A armazenagem estendida dos dados do portador de cartão que exceda as necessidades do negócio cria um risco desnecessário. Os únicos dados do portador de cartão que podem ser armazenados são o número de conta primária ou PAN (tornado ilegível), data de vencimento, nome e código de serviço. Lembre-se, se você não necessita, não armazene!

3.2 Não armazenar dados críticos de autenticação após a autorização (nem mesmo codificados). Os dados críticos de autorização incluem os dados mencionados nas Exigências de 3.2.1 a 3.2.3 a seguir:

Um dado confidencial de autenticação é composto pelo dado da tarja magnética (ou trilha) 6, código de validação do cartão ou valor 7 e dado do PIN 8. A armazenagem do dado confidencial de autenticação é proibida! Este dado tem muito valor para os hackers na medida em que ele permite gerar cartões de pagamentos e também criar transações fraudulentas. Ver “PCI DSS Glossário, Abreviações e Acrônimos” para obter uma definição completa do “dado confidencial de autenticação.”

6 Dado codificado na tarja magnética usado para a autorização durante uma transação com cartão presente. As organizações não podem reter os dados completos da tarja

magnética após a autorização de uma transação. Os únicos elementos do dado da trilha que podem ser retidos são o número da conta, data do vencimento e o nome. 7 Valor de três ou quatro dígitos impresso sobre ou ao lado do painel de assinatura ou na face de um cartão de pagamento que é usado para verificação em transações de cartão

ausente. 8 Código de Identificação Pessoal digitado pelo portador de cartão durante uma transação com cartão presente, e/ou bloco de PIN codificado presente na mensagem da transação.


Exigência Diretriz

3.2.1 Não armazenar o conteúdo total de qualquer trilha da tarja magnética (que está no verso de um cartão, em um chip ou em qualquer outro lugar). Estes dados são alternativamente chamados de dados da trilha completa, da trilha, da trilha 1, da trilha 2 e da tarja magnética. No curso normal do negócio, os seguintes elementos dos dados da tarja magnética podem ter que ser mantidos: o nome do titular da conta, número de conta primária (PAN), data do vencimento e código de serviço. Para minimizar o risco, armazene apenas os elementos dos dados que não sejam necessários ao negócio. NUNCA armazene o código de verificação do cartão, o valor ou os elementos dos dados do valor de verificação do PIN.

Nota: Consultar o “Glossário, Abreviações e Acrônimos” para obter informações adicionais.

Se o dado completo da trilha for armazenado, os hackers que obtiverem este dado podem reproduzir e vender cartões de pagamento ao redor do mundo. O armazenamento do dado total da trilha também viola os regulamentos operacionais das marcas de pagamento e pode levar a multas e penalidades.

3.2.2 Não armazenar o código ou valor de validação do cartão (valor de três ou quatro dígitos impressos na frente ou verso de um cartão de pagamento, usados, por exemplo, para verificar as transações com cartão ausente).

Nota: Consultar o “Glossário, Abreviações e Acrônimos” para obter informações adicionais.

O propósito do código de validação do cartão é proteger as transações com cartões ausentes (transações via Internet ou correios / telefone (MO/AO)), onde o consumidor e o cartão não se encontram presentes. Estes tipos de transações podem ser autenticados como pertencentes ao dono do cartão apenas através da solicitação do código de validação do plástico, visto que o dono do cartão o tem em mãos e pode ler o valor. Se este dado proibido for armazenado e subseqüentemente roubado, os hackers podem executar transações fraudulentas e MO/AO. Esta armazenagem também viola os regulamentos operacionais das marcas de pagamento e pode levar a multas e penalidades.

3.2.3 Não armazenar os números de identificação pessoal (PIN) ou o bloqueador do PIN codificado.

Estes valores devem ser conhecidos apenas pelo dono do cartão ou banco que emitiu o cartão. Se este dado proibido for armazenado e subseqüentemente roubado, os hackers podem executar transações de débito baseadas em PIN (ex: saque em ATM). Esta armazenagem também viola os regulamentos operacionais das marcas de pagamento e pode levar a multas e penalidades.


Exigência Diretriz

3.3 Ocultar o PAN quando exibido (os primeiros seis ou quatro últimos dígitos são o número máximo de dígitos que devem ser mostrados).

Nota: Esta exigência não se aplica aos funcionários e outros que possuam a necessidade específica de ver o PAN completo; ou substitui exigências mais rígidas em vigor referentes à exibição dos dados do portador de cartão (por exemplo, nos comprovantes do ponto de venda (POS)).

Exibir a totalidade do PAN em itens tais como telas de computador, recibo de cartões de pagamento, faxes, ou relatórios de papel pode fazer com que este dado seja obtido por indivíduos não autorizados e usados de forma fraudulenta. Favor notar que este dado pode ser exibido em sua totalidade na “cópia do recibo do estabelecimento”, ou para aqueles que possuem a necessidade de ver o PAN completo.

3.4 Tornar pelo menos o PAN ilegível em qualquer local em que seja armazenado (incluindo os dados em mídia digital portátil, mídia de backup, em relatórios e dados recebidos ou armazenados por redes wireless) através do uso de qualquer uma das seguintes técnicas:

A falta de proteção do PAN pode permitir que um usuário não autorizado interno e criminosos vejam ou baixem este dado. Os PANs mantidos na armazenagem primária (banco de dados ou “flat files” tais como arquivos de texto e planilhas) bem como armazenagem não primária (backup, registros de auditoria e registros de exceção ou resolução de erros) devem ser totalmente protegidos. O dano por roubo ou perda de fitas de backup durante o transporte pode ser reduzido ao assegurar que os PANs sejam tornados ilegíveis via codificação, truncagem ou hashing. Visto que os registros de auditoria, resolução de erro e exceção devem ser retidos, você pode prevenir a divulgação do dado nos registros tornando os PANs ilegíveis (removendo ou mascarando os mesmos).

• Funções one-way hashes (hashed indexes) fortes.

Funções do tipo one-way hash como as SHA-1 podem ser usadas para tornar ilegíveis os dados do portador de cartão. As funções hash são apropriadas quando não há a necessidade de resgatar o número original (one-way hashes são irreversíveis).

• Truncagem. O intento da truncagem é de que apenas uma parte (que não exceda os primeiros seis e últimos quatro dígitos) do PAN seja armazenada. Isto é diferente de mascarar, onde a totalidade do PAN é armazenado, mas é mascarado quando exibido (ou seja, apenas uma parte do PAN é mostrada nas telas, relatórios, recibos, etc.).

• Tokens de indexação e PADs (os PADs devem ser armazenados de forma segura).

Index tokens e pads podem também ser usados para tornar os dados do portador de cartão ilegíveis. Um “index token” é um token criptográfico que substitui o PAN baseado em um determinado índice de valor imprevisível. Um “one-time pad” é um sistema no qual uma chave privada gerada aleatoriamente, é usada apenas uma vez ao codificar a mensagem que é então decodificada usando uma chave combinada com um “one-time pad”.


Exigência Diretriz

• Codificação rigorosa associada com processos e procedimentos de administração de chave.

O intento de uma criptografia forte (strong cryptography - ver a definição de comprimento de chaves no “PCI DSS Glossário, Abreviações e Acrônimos”) é de que a codificação seja baseada em um algoritmo testado e aceito pela indústria (não um algoritmo proprietário ou "criado em casa"). O PAN é a informação MÍNIMA da conta que

necessita ser tornada ilegível. Se por alguma razão, uma companhia não for capaz de codificar os dados do portador de cartão, consultar o Anexo B – Controles de Compensação para a Codificação dos Dados Armazenados.

3.4.1 Se a codificação do disco for usada (em vez da codificação do banco de dados a nível de coluna ou arquivo), o acesso lógico deve ser administrado de forma independente dos mecanismos de controle de acesso do sistema operacional nativo (por exemplo, não usando as contas do sistema local ou do Diretório Ativo). As chaves de decodificação não devem estar ligadas às contas dos usuários.

O objetivo desta exigência é atender a aceitação da codificação do disco para tornar os dados do portador de cartão ilegíveis. A codificação do disco encripta os dados armazenados no dispositivo de armazenamento do computador e automaticamente decodifica a informação quando solicitado por um usuário autorizado. O sistema de codificação do disco intercepta as operações de leitura e escrita do sistema operacional e executa as transformações criptográficas devidas, sem necessidade de qualquer ação pelo usuário que não seja a digitação da senha ou frase no início da sessão. Com base nestas características de codificação de disco e para estar em conformidade com esta exigência, o método de codificação do disco não pode ter: 1) Uma associação direta com o sistema operacional, ou 2) Chaves de decodificação que estejam associadas com as contas do usuário.

3.5 Proteja as chaves de codificação usadas para a codificação dos dados do portador de cartão contra a divulgação e o uso indevido.

As chaves de codificação devem ser fortemente protegidas porque aqueles que tiverem acesso serão capazes de decodificar os dados.

3.5.1 Restrinja o acesso às chaves ao menor número de custódios necessários.

Deve haver um pequeno número de pessoas que tem que ter acesso às chaves de codificação, usualmente apenas aqueles que possuem a responsabilidade de custódios das chaves.

3.5.2 Guarde as chaves de forma segura no menor número de modalidades e lugares possíveis.

As chaves de codificação devem ser armazenadas de forma segura, usualmente codificadas com chaves de codificação de chave (key-encrypting keys) e armazenadas em poucos lugares.


Exigência Diretriz

3.6 Documentar completamente e implementar a totalidade dos processos e procedimentos de administração das chaves para aquelas usadas na codificação dos dados do portador de cartão, incluindo o seguinte:

A maneira pela qual as chaves são administradas é uma parte crítica da segurança contínua da solução de codificação. Um bom processo de administração de chave, seja manual ou automático, atende a todas as exigências da chave de 3.6.1 até 3.6.10.

3.6.1 Geração de chaves fortes. A solução de codificação deve gerar chaves fortes, conforme o definido no “PCI DSS Glossário, Abreviações e Acrônimos” sob "strong cryptography".

3.6.2 Distribuição segura das chaves. A solução de codificação deve distribuir as chaves de forma segura, significando que as chaves não são distribuídas abertamente e apenas aos custódios identificados em 3.5.1.

3.6.3 Armazenamento seguro das chaves. A solução de codificação deve armazenar as chaves de forma segura, significando que as chaves não são armazenadas abertamente (devem ser codificadas por uma chave de codificação de chaves “key-encryption key”).

3.6.4 Mudança periódica das chaves. • Se considerada necessária pela sua

aplicação (por exemplo, re-keying), de preferência automática.

• No mínimo anualmente.

Se oferecido pelo fornecedor de um aplicativo de codificação, siga quaisquer recomendações ou processos deste provedor para as mudanças periódicas das chaves. A mudança anual das chaves de codificação é imperativa para minimizar o risco de alguém obter a chave de codificação e ser capaz de decifrar os dados.

3.6.5 Destruição das chaves antigas. As chaves antigas que não são mais usadas ou necessárias devem ser destruídas. Se as chaves antigas tiverem que ser mantidas (para dar suporte a arquivos ou dados codificados, por exemplo) elas devem ser fortemente protegidas. (Ver a exigência 3.6.6 abaixo)

3.6.6 Conhecimento compartilhado e estabelecimento de duplo controle das chaves (sendo necessária a existência de duas ou três pessoas, cada uma conhecendo apenas a sua parte da chave, para reconstruir a chave completa).

O conhecimento compartilhado e controle duplo são usados para eliminar a possibilidade de uma pessoa ter acesso ao conteúdo completo da chave. Este controle é usualmente aplicável para os sistemas manuais de codificação de chaves, ou onde a administração da chave não é implementada pelo produto de codificação. Este tipo de controle é usualmente implantado dentro dos dispositivos de módulo de segurança.

3.6.7 Prevenção contra a substituição não autorizada das chaves.

A solução de codificação não deve permitir ou aceitar a substituição de chaves vinda de fontes não autorizadas ou processos que venham de forma inesperada.


Exigência Diretriz

3.6.8 Reposição das chaves conhecidas ou suspeitas de comprometimento.

A solução de codificação não deve permitir ou facilitar um processo de substituição de chaves que seja suspeito ou considerado como tendo sido comprometido.

3.6.9 Cancelamento das chaves antigas ou inválidas.

Isto irá garantir que as chaves não possam mais ser usadas.

3.6.10 Exigência de que os custódios das chaves assinem um documento especificando que eles compreendem e aceitam as responsabilidades de custódios das chaves.

Este processo irá assegurar que o indivíduo aceita e compreende suas responsabilidades como custódio da chave.


Exigência 4: Codificar a transmissão dos dados do portador de cartão que transitam nas redes públicas abertas As informações confidenciais devem ser codificadas durante a transmissão através de redes que sejam fáceis para um hacker interceptar, modificar e redirecionar os dados quando em trânsito.

Exigência Diretriz

4.1 Usar técnicas de codificação e protocolos de segurança, tais como Secure Sockets Layer (SSL) / Transport Layer Security (TLS) e Internet Protocol Security (IPSEC) para proteger os dados confidenciais do portador de cartão durante a transmissão através de redes públicas abertas.

Exemplos de redes públicas abertas que estão no âmbito do PCI DSS são a Internet, WiFi (IEEE 802. 11x), global system for mobile communications (GSM) e general packet radio service (GPRS).

A informação confidencial deve ser codificada durante a transmissão sobre as redes públicas, porque é comum e fácil para um hacker interceptar e/ou desviar os dados quando em trânsito. Favor notar que as versões do SSL anteriores à v 3.0 possuem vulnerabilidades documentadas, tais como buffer overflows, que um atacante pode usar para ter acesso e controlar o sistema afetado.


Exigência Diretriz 4.1.1 Para as redes wireless transmitindo os

dados do portador de cartão, codificar as transmissões através do uso da tecnologia Wi-Fi Protected Acess (WPA ou WPA2), IPSEC, VPN ou SSL/TLS. Nunca confiar exclusivamente na privacidade equivalente via cabo (wired equivalent privacy - WEP) para proteger a confidencialidade e acesso para uma LAN wireless. Se a WEP for usada, faça o seguinte:

• Use com uma chave de codificação de 104-bit e um valor de inicialização de 24-bit, no mínimo.

• Use APENAS em conjunto com a tecnologia Wi-Fi Protected Acess (WPA ou WPA2), VPN ou SSL/TLS.

• Faça a rotação das chaves WEP compartilhadas sempre que existirem mudanças das pessoas que tenham acesso às chaves.

• Restrinja o acesso com base no endereço do código de acesso da mídia (media acess code – MAC).

Os hackers usam ferramentas amplamente disponíveis para “eavesdrop” as comunicações wireless. O uso da codificação apropriada pode prevenir o eavesdropping e divulgação da informação confidencial através da rede. Muitos dos comprometimentos conhecidos de dados armazenados do portador de cartão se originam apenas na rede convencional com cabos, quando um hacker tem acesso a partir de uma rede wireless. Uma codificação WEP nunca deve ser usada sozinha por ser vulnerável em função dos fracos vetores iniciais (IV) em um processo de troca de chave WEP e falta da rotatividade de chaves exigida. Um atacante pode usar as ferramentas de força bruta largamente disponíveis para penetrar em uma codificação WEP.

4.2 Nunca envie um PAN não codificado por e-mail. Um e-mail pode ser facilmente interceptado por um “packet-sniffing” durante o itinerário de entrega através das redes internas e públicas.


Diretrizes para as Exigências 5 e 6: Manter um Programa de Administração da Vulnerabilidade

Exigência 5: Usar e atualizar regularmente os softwares ou programas antivírus Muitas das vulnerabilidades e vírus insidiosos entram na rede através das atividades de e-mail dos funcionários. Deve ser usado um software antivírus em todos os sistemas comumente afetados por vírus para proteger os sistemas contra estes softwares maliciosos s.

Exigência Diretriz

5.1 Instale mecanismos antivírus em todos os sistemas geralmente afetados por vírus (especialmente computadores pessoais e servidores). Nota: Os sistemas comumente afetados por vírus tipicamente não incluem mainframes ou sistemas operacionais com base em Unix.

Existe um fluxo constante de ataques utilizando meios amplamente divulgados, geralmente "0 dias" (publicados e divulgados através das redes em até uma hora após a sua descoberta) contra sistemas seguros. Sem um software antivírus que seja atualizado regularmente, estes novos vírus podem atacar e desabilitar a sua rede.

5.1.1 Assegure-se de que os programas antivírus são capazes de detectar, remover e proteger contra outras formas de softwares insidiosos, incluindo spyware e adware.

É importante se proteger contra TODOS os tipos e formas de softwares insidiosos.

5.2 Assegure-se de que todos os mecanismos antivírus estejam atualizados, rodando ativamente e capazes de gerar registro (logs) para auditoria.

O melhor software antivírus tem a sua eficiência limitada se não possuir as assinaturas antivírus atualizadas ou se não estiver ativo na rede ou em um computador individual. Os registros de auditoria oferecem a habilidade de monitorar a atividade de vírus e reação antivírus.


Exigência 6: Desenvolver e manter seguros os sistemas e aplicativos Indivíduos inescrupulosos usam as vulnerabilidades de segurança para obter acesso privilegiado aos sistemas. Muitas destas vulnerabilidades são resolvidas através de patches de segurança fornecidos pelos prestadores de serviço. Todos os sistemas devem ter os patches de software mais atualizados e apropriados para se proteger contra o abuso por parte dos funcionários, hackers externos e vírus. Nota: Os patches de software apropriados são aqueles que foram suficientemente avaliados e testados de modo a determinar que os mesmos não entrem em conflito com as configurações de segurança existentes. Para os aplicativos desenvolvidos in-house, inúmeras vulnerabilidades podem ser evitadas através do uso de processos de desenvolvimento de sistemas e técnicas de codificação seguras.

Exigência Diretriz

6.1 Assegurar-se de que todos os componentes do sistema e software possuem instalados os mais recentes patches de segurança fornecidos pelo prestador de serviço. Instalar os patches de segurança em, no máximo, um mês após o lançamento dos mesmos.

Existe um fluxo constante de ataques utilizando meios amplamente divulgados, geralmente "0 dia" (publicados e divulgados através das redes em até uma hora após a sua descoberta) contra sistemas seguros. Sem a implementação dos patches mais recentes nos sistemas, o mais rápido possível, um hacker pode usar estes meios para atacar e desabilitar a rede. Considere dar prioridade às mudanças de forma a que os patches de segurança importantes possam ser instalados nos sistemas críticos em, no mínimo, 30 dias, enquanto que outra mudança de menor risco recebe uma prioridade mais baixa.

6.2 Estabelecer um processo para identificar as vulnerabilidades de segurança recém descobertas (por exemplo, assinatura de serviços de alerta disponíveis gratuitamente na Internet). Atualize os padrões para fazer face às novas modalidades de vulnerabilidade.

A intenção desta exigência é que a organização seja mantida atualizada em termos de novas vulnerabilidades de forma a que possa proteger apropriadamente a sua rede e incorpore as vulnerabilidades recentemente descobertas em seus padrões de configuração.

6.3 Desenvolver software e aplicativos baseados nas melhores práticas da indústria e inclua a segurança da informação ao longo de todo o ciclo de vida do desenvolvimento do programa.

Sem a inclusão da segurança durante a definição das exigências, análise do design, fase de análise e teste do desenvolvimento do software, as vulnerabilidades de segurança podem ser introduzidas de forma insidiosa ou por acaso no ambiente de produção.

6.3.1 Teste de todos os patches de segurança e mudanças das configurações do sistema e software antes da implantação.

Assegure-se de que todas as instalações e mudanças são executadas conforme esperado e que não são aceitas nenhumas funções que sejam inesperadas, indesejáveis e prejudiciais.


Exigência Diretriz

6.3.2 Ambientes de desenvolvimento, teste e produção separados.

Geralmente os ambientes de desenvolvimento e teste são menos seguros do que o de produção. Sem uma separação adequada, os ambientes de produção e de dados do portador de cartão podem estar sujeitos a risco devido às vulnerabilidades ou debilidade dos processos internos.

6.3.3 Separação dos ambientes e tarefas de desenvolvimento, teste e produção.

Isto minimiza o número de pessoas com acesso ao ambiente de produção e dados do portador de cartão e ajuda a assegurar que o acesso seja limitado aos que realmente necessitam ter acesso.

6.3.4 Produção de dados (PANs reais) não devem ser usados para teste ou desenvolvimento.

Os controles de segurança não são geralmente tão rigorosos no ambiente de desenvolvimento. O uso do dado de produção permite que tanto os hackers potenciais, como o pessoal de desenvolvimento, tenham a oportunidade de obter o acesso não autorizado à informação de produção.

6.3.5 Remoção dos dados de teste e contas antes que os sistemas de produção se tornem ativos.

O dado e contas de teste devem ser removidos do código de produção antes que o aplicativo se torne ativo, visto que estes itens podem permitir o acesso à informação sobre o funcionamento da aplicação. A posse de tais informações pode facilitar o comprometimento do aplicativo e dados relacionados do portador de cartão.

6.3.6 Remoção das contas personalizadas, nome do usuário e senhas antes que os aplicativos se tornem ativos ou sejam liberados para os clientes.

Aplicativos customizados de contas, nome de usuário e senhas devem ser removidos do código de produção antes que o aplicativo se torne ativo ou seja divulgado para os clientes, tendo em vista que estes itens podem permitir o acesso às informações sobre o funcionamento do aplicativo. A posse de tal informação pode facilitar o comprometimento do aplicativo e dados relacionados do portador de cartão.

6.3.7 Revisão dos códigos customizados antes da liberação para a produção ou clientes, objetivando a identificação de qualquer vulnerabilidade potencial do código.

As vulnerabilidades de segurança em códigos customizados são geralmente exploradas por hackers ao ganhar acesso à rede e comprometer os dados do portador de cartão. Aqueles com conhecimento das técnicas de código seguro devem rever o código para identificar as vulnerabilidades.


Exigência Diretriz

6.4 Acompanhar as mudanças nos procedimentos de controle de todo o sistema e mudanças na configuração do software. Os procedimentos devem incluir o seguinte:

Sem o controle apropriado das mudanças nos softwares, as características podem ser deliberada ou inadvertidamente omitidas ou tornadas inoperáveis, podem ocorrer irregularidades no processamento ou introduzidos códigos insidiosos. Se as políticas de atestado de idoneidades relacionadas com os funcionários e controle dos sistemas de acesso não forem adequadas, existe o risco de que indivíduos inescrupulosos ou sem o devido treinamento tenham acesso irrestrito ao código de software, funcionários demitidos podem ter a oportunidade de comprometer os sistemas e ações não autorizadas podem não ser detectadas.

6.4.1 Documentação do impacto. O impacto da mudança deve ser documentado de forma a que todas as partes afetadas sejam capazes de fazer um planejamento apropriado para quaisquer mudanças no processamento.

6.4.2 Administração do “sign-off” para as partes apropriadas.

A aprovação pela administração significa que uma mudança é legítima e autorizada pela organização.

6.4.3 Teste da funcionalidade operacional. Deve ser executado um teste completo para verificar se todas as ações são as esperadas, que os relatórios sejam fidedignos e que a reação a todas as possíveis condições de erros seja apropriada.

6.4.4 Procedimentos de back-out. Para cada mudança, deve haver um procedimento de back-out para o caso de que a mudança venha a falhar, permitindo a volta ao estado anterior.

6.5 Desenvolver todos os aplicativos de web baseados em diretrizes de codificação seguras tais como as diretrizes do Open Web Application Security Project. Revise o código dos aplicativos customizados para identificar as vulnerabilidades do código. Verifique a prevenção das vulnerabilidades mais comuns no processo de desenvolvimento dos códigos dos softwares para incluir o seguinte:

A camada de aplicativos corre um alto risco e pode ser o alvo de ameaças tanto externas como internas. Sem a segurança apropriada, os dados do portador de cartão e outras informações apropriadas da organização podem ser expostos, resultando em prejuízos tanto para ela como para seus clientes e sua reputação.

6.5.1 Input não validado. As informações às requisições originadas na web devem ser validadas antes de serem enviadas ao aplicativo de web, por exemplo, deve ser feito uma checagem de todos os caracteres alfa, mix de alfa e numéricos, etc. Sem estas verificações, os hackers podem passar informações inválidas para um aplicativo e atacar os componentes dentro da rede, através deste aplicativo.


Exigência Diretriz

6.5.2 Quebra do controle de acesso (por exemplo, uso desonesto dos IDs dos usuários).

Usuários mal intencionados s geralmente tentam fazer um scanning e enumerar as contas dos usuários existentes nos aplicativos de forma a encontrar um ponto de entrada para o ataque. Uma vez que seja encontrada uma conta existente, um atacante irá tentar usar as senhas padrão ou força bruta para ter acesso ao aplicativo.

6.5.3 Quebra da administração de autenticação / sessão (uso das credenciais da conta e cookies da sessão).

As credenciais das contas e session tokens devem ser devidamente protegidos. Os ataques às senhas, chaves, session cookies, ou outro tokens podem derrotar as restrições às autenticações e permitir que os hackers assumam a identidade de outros usuários. Adicionalmente, os cookies podem armazenar a informação do portador de cartão e são por default armazenados em clear text.

6.5.4 Ataques ao cross-site scripting (XSS). Com estes ataques, um aplicativo de web pode ser usado para enviar um ataque ao browser do usuário final, que pode resultar na divulgação do session token do mesmo, em um ataque à máquina do usuário final e em um hacker podendo enviar um conteúdo spoofed para enganar o usuário.

6.5.5 Overflow do buffer. Os hackers podem causar uma falha nos componentes do aplicativo de web que não validem corretamente o input (ver também a diretriz 6.5.1 acima) e podem ser capazes de atacar o controlador de processos no servidor relacionado.

6.5.6 Defeitos de injection (por exemplo, injeção de structured query language injection - SQL).

Ao acelerar a conectividade e reduzir a performance no lado do servidor, é geralmente exigida a validação do input pelo lado do cliente e manipulação do dado. Geralmente trata-se apenas de um exercício trivial para que os hackers possam fazer o bypass deste controle e usar um aplicativo de web ao enviar comandos insidiosos ao servidor e iniciar ataques tais como buffer overflows, ou ao revelar tanto a informação confidencial como a funcionalidade de um aplicativo de servidor. Este é também um meio popular de efetuar transações fraudulentas no sites de e-commerce.


Exigência Diretriz

6.5.7 Administração incorreta dos erros. Geralmente o gerenciamento incorreto do erro fornece informações que ajudam um hacker no comprometimento de um sistema. Se um hacker puder criar erros que o aplicativo de web não seja capaz de gerenciar corretamente, eles podem ter acesso às informações detalhadas do sistema, criar interrupções por recusa de execução de serviços (denial-of-service), causar falhas de segurança, ou tornar o servidor não operacional. Por exemplo, a mensagem “senha incorreta” (incorrect password provided) diz a eles que o nome de usuário dado foi correto e que devem apenas concentrar seus esforços na senha. Use mensagens de erro mais genéricas, como "o dado não pôde ser verificado” (data could not be verified).

6.5.8 Armazenagem insegura. Isto se relaciona com o uso não seguro da codificação. Tendo em vista que os aplicativos de senha são difíceis de codificar apropriadamente, isto freqüentemente resulta em fraca proteção do dado armazenado e codificação que é fácil de quebrar.

6.5.9 Recusa de serviço. Os hackers podem consumir os recursos dos aplicativos de web até o ponto em que outros usuários não possam mais usar o aplicativo. Os hackers também podem trancar os usuários fora de suas contas ou causar uma falha do aplicativo.

6.5.10 Administração de configuração insegura. Instalar uma forte configuração de servidor é fundamental para contar com aplicativos de web seguros. Os servidores possuem muitas opções de configuração para controlar a segurança e não são seguros fora da caixa.

6.6 Assegurar-se de que todos os aplicativos que funcionam por meio da web estejam protegidos contra ataques conhecidos, através dos seguintes métodos:

Os ataques aos aplicativos voltados para a web são comuns e geralmente têm sucesso em decorrência do uso de códigos de má qualidade. Estas exigências para a revisão dos códigos dos aplicativos ou firewalls da camada de aplicativo têm o objetivo de reduzir consideravelmente o número de comprometimentos nos aplicativos voltados para a web que resultam na quebra da proteção aos dados do portador de cartão.

• Ter todos os códigos de aplicativos customizados revisados para a busca de vulnerabilidades comuns através de uma organização que se especialize em segurança de aplicativo.

Uma ferramenta que executa a revisão dos códigos e/ou scans das vulnerabilidades dos aplicativos pode também ser usada para satisfazer esta exigência.


Exigência Diretriz

• Instalar uma camada de aplicativos (application layer) de firewall na frente dos aplicativos voltados para a web. Nota: Este método é considerado uma melhor prática até 30 de junho de 2008 e depois dessa data se tornará uma exigência.

Os aplicativos de firewalls são usados para filtrar e bloquear o tráfego não essencial da camada do aplicativo. Usado em conjunto com um firewall baseado na rede, um firewall da camada de aplicativo apropriadamente configurado previne os ataques a esta camada caso os mesmos estejam inadequadamente codificados ou configurados.

Diretrizes para as Exigências 7, 8 e 9: Implementar Medidas Rígidas de Controle ao Acesso

Exigência 7: Restringir o acesso aos dados do portador de cartão a apenas aqueles que necessitam conhecê-los para a execução dos trabalhos Esta exigência garante que os dados críticos possam ser acessados apenas por pessoas autorizadas.

Exigência Diretriz

7.1 Limitar o acesso aos recursos de computação e informação do portador de cartão apenas aos indivíduos cuja execução de tarefa exija tal acesso.

Quanto maior o número de pessoas tendo acesso aos dados do portador de cartão, maior o risco de que a conta do usuário seja usada maliciosamente. Limitando o acesso àqueles que possuem uma forte razão orientada para o negócio ajuda a sua organização a prevenir a má administração dos dados do portador de cartão em função de inexperiência ou malícia. A sua organização deve criar uma clara política para controlar o acesso ao dado ou definir como e quem pode acessar o dado.

7.2 Estabelecer um mecanismo para os sistemas com múltiplos usuários que restrinja o acesso com base naqueles que tenham a necessidade de saber e o ajuste para “negar tudo”, a menos que especificamente autorizado.

Sem um mecanismo para restringir o acesso com base na necessidade de saber pelo usuário, o mesmo pode vir a ter o acesso de forma inadvertida aos dados do portador de cartão.


Exigência 8: Atribuir um ID único para cada pessoa que possua acesso ao computador Designando uma identificação única (ID) a cada pessoa com acesso assegura que as ações tomadas com respeito aos dados e sistemas críticos sejam executadas por usuários conhecidos e autorizados que possam ser acompanhados e verificados.

Exigência Diretriz

8.1 Identificar todos os usuários com um nome de usuário único antes que tenham permissão para acessar os componentes do sistema ou os dados do portador de cartão.

Ao assegurar que cada usuário é identificado de forma individual — ao invés de usar um único ID para diversos funcionários — uma organização pode manter os indivíduos responsáveis por suas ações e um acompanhamento de auditoria eficiente por funcionário. Isto ajuda a acelerar a resolução de questões e contenção quando ocorre um mau uso ou intento mal intencionado.

8.2 Além de designar um ID único, utilizar pelo menos um dos métodos abaixo, em adição a uma identificação exclusiva, para autenticar todos os usuários: • Senha. • Dispositivos de identificação física (ex: ID de

segurança, certificados ou chaves públicas, tokens).

• Autenticação biométrica.

Estes itens de autenticação, quando usados em conjunto com um ID único para cada pessoa, ajuda a proteger contra o comprometimento dos IDs únicos dos usuários (visto que aquele que tentar o comprometimento terá a necessidade de saber o ID único, a senha ou outro item de autenticação).

8.3 Implementar a autenticação por dois fatores para o acesso remoto à rede pelos funcionários, administradores e prestadores de serviço. Usar tecnologias tais como a remote authentication and dial-in service (RADIUS) ou o terminal access controller access control system (TACACS) com tokens ou VPN (baseado no SSL/TLS ou IPSEC) com certificados individuais.

As tecnologias de autenticação de dois fatores (two-factor authentication) oferecem uma senha temporária de uso único, a ser usada quando for necessário um item adicional de autenticação para os acessos de alto risco, como aqueles externos à sua rede. Para segurança adicional, a sua organização também pode considerar o uso da autenticação de dois fatores ao acessar as redes de alta segurança a partir de redes de baixa segurança (por exemplo, a partir de computadores tipo desktop corporativo (baixo nível de segurança) ou servidores de produção / bancos de dados com dados do portador de cartão (alta segurança)).

8.4 Codificar todas as senhas durante a transmissão e armazenamento em todos os componentes do sistema.

Muitos dispositivos de rede e aplicativos transmitem o ID de usuário e a senha não codificada através da rede e/ou também armazena as senhas sem codificação. Um hacker pode facilmente interceptar o ID de usuário codificado e a senha durante a transmissão usando um “sniffer,” ou acessar diretamente o ID de usuários e senhas não codificadas nos arquivos onde estão armazenados e usar este dado roubado para obter o acesso não autorizado.


Exigência Diretriz

8.5 Garantir a autenticação eficiente do usuário e administração da senha para os usuários não consumidores e administradores em todos os componentes do sistema, como a seguir:

Visto que um dos primeiros passos que um hacker irá tomar para o comprometimento do sistema é o de explorar as senhas fracas ou não existentes, é importante a implementação de bons processos para a autenticação do usuário e administração da senha.

8.5.1 Controlar a adição, exclusão e modificação dos IDs de usuários, credenciais e outros métodos de identificação.

Ao assegurar que os usuários adicionados aos seus sistemas são todos válidos e reconhecidos, a adição, retirada e modificação do ID de usuários deve ser administrada e controlada por um pequeno grupo com autoridade específica. A habilidade de administrar estes ID de usuários deve ser limitada a apenas este pequeno grupo.

8.5.2 Verificar a identidade do usuário antes de executar a mudança de senhas.

Muitos hackers usam "social engineering” — por exemplo, chamando uma central de atendimento e agindo como um usuário legítimo — ou ter a senha mudada de forma a que possam usar um ID de usuário. Considere o uso de uma “pergunta secreta” que apenas o próprio usuário pode responder para ajudar os administradores a identificar o usuário antes de mudar as senhas. Certifique-se de que tais perguntas estão devidamente protegidas e não divulgadas.

8.5.3 Estabelecer senhas de uso inicial com um valor único para cada usuário e faça uma mudança imediata após ser usada pela primeira vez.

Se a mesma senha for usada para a instalação de cada novo usuário, um usuário interno, ex-funcionário, ou hacker pode conhecê-la ou descobri-la facilmente e usá-la para ter acesso às contas.

8.5.4 Revogar imediatamente o acesso por usuários cancelados.

Se um funcionário deixar a organização e ainda tiver acesso à rede por intermédio de sua conta de usuário, pode ocorrer o acesso desnecessário ou insidioso aos dados do portador de cartão. Este acesso pode ser gerado a partir de um ex-funcionário ou usuário mal intencionado que se utiliza de uma conta de usuário antiga ou inativa. Considere a implementação de um processo com RH para a comunicação imediata de quando um funcionário é demitido para que a conta possa ser rapidamente apagada.

8.5.5 Remover as contas de usuários inativos pelo menos a cada 90 dias.

A existência de contas inativas permite que um usuário não autorizado se utilize da conta inativa para o acesso potencial aos dados do portador de cartão.


Exigência Diretriz

8.5.6 Habilitar as contas usadas pelos prestadores de serviço para a manutenção remota apenas durante o período de tempo estritamente necessário.

A permissão aos fornecedores (por exemplo, como os vendedores de POS) para ter acesso à sua rede em bases do tipo 24/7 caso necessitem dar suporte aos seus sistemas, aumenta as chances de um acesso não autorizado, tanto a partir de um usuário no ambiente do fornecedor como a partir de um hacker que tenha encontrado e esteja usando este ponto de entrada para a sua rede, sempre disponível. Favor consultar também as exigências 12.3.8 e 12.3.9 para obter maiores informações sobre este tópico.

8.5.7 Divulgar os procedimentos de senha e os regulamentos para todos os usuários que possuam acesso aos dados do portador de cartão.

Ao divulgar os procedimentos de senha a todos os usuários, você os ajuda a entender e a seguir estas políticas e estar alerta para quaisquer usuários mal intencionados que possam tentar se aproveitar de suas senhas para ganhar acesso aos dados do portador de cartão (por exemplo, ligando para um funcionário e pedido a sua senha de forma a que ele possa “resolver um problema”).

8.5.8 Não utilizar senhas e contas genéricas, de grupo ou compartilhadas.

Se múltiplos usuários compartilharem da mesma conta e senha, torna-se impossível determinar a responsabilidade pelas ações de um indivíduo, visto que a ação pode ter sido executada por qualquer um no grupo que compartilha a conta e senha.

8.5.9 Mudar as senhas dos usuários pelo menos a cada 90 dias.

Senhas fortes são a primeira linha de defesa dentro de uma rede, visto que um hacker irá geralmente tentar primeiro encontrar as contas com senhas fracas ou inexistentes. Existe mais tempo para um atacante buscar estas contas fracas e comprometer a rede sob o disfarce de um ID de usuário válido, se as senhas forem curtas e fáceis de adivinhar, ou válidas por um longo tempo sem mudança. As senhas fortes podem ser vigiadas e mantidas em termos destas exigências se forem habilitadas as características de segurança das contas e senhas que vêm com o seu sistema operacional (por exemplo, Windows), redes, banco de dados e outras plataformas.

8.5.10 Exigir uma senha com o comprimento mínimo de pelo menos sete caracteres.

8.5.11 Usar senhas contendo caracteres tanto numéricos como alfabéticos.

8.5.12 Não permitir que um indivíduo submeta uma nova senha que seja idêntica a qualquer uma das quatro últimas que ele tenha usado.

8.5.13 Limitar a tentativa de acesso repetido por razão de bloqueio do ID do usuário a não mais de seis tentativas.

Sem os mecanismos de “account-lockout” instalados, um atacante pode tentar continuamente adivinhar a senha através de ferramentas manuais ou automáticas (password cracking), até que possam ter sucesso e acessar a conta do usuário.

8.5.14 Ajustar a duração do bloqueio para trinta minutos ou até que o administrador habilite o ID do usuário.

Se uma conta se encontra bloqueada devido a alguém tentando adivinhar a senha, os controles podem retardar a reativação destas contas bloqueadas para impedir que o hacker continue a tentar adivinhar a senha (eles terão que


Exigência Diretriz parar por pelo menos 30 minutos até que a conta seja reativada). Adicionalmente, se a reativação deve ser solicitada, o administrador ou central de atendimento pode validar se o proprietário da conta é a causa (por erro de digitação) do bloqueio.

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

Quando os usuários se afastam de uma máquina em funcionamento e conectada com acesso à rede crítica ou dados do portador de cartão, esta máquina pode ser usada por outros na ausência do usuário, resultando em um acesso não autorizado e/ou uso indevido da conta.

8.5.16 Autenticar todo o acesso a qualquer banco de dados contendo os dados do portador de cartão. Estes incluem o acesso via aplicativos, administradores e todos os demais usuários.

Sem a autenticação do banco de dados, o potencial para o acesso não autorizado ou insidioso ao este banco aumenta e tal acesso não pode ser registrado visto que o usuário não foi autenticado e portanto não é conhecido pelo sistema. Também, o acesso ao banco de dados deve ser sempre feito através de procedimentos programados e armazenados, ao invés de via acesso direto ao banco de dados pelos usuários finais (exceto pelos DBAs, que podem ter acesso direto ao banco de dados para seus trabalhos administrativos).


Exigência 9: Restringir ao máximo o acesso físico aos dados do portador de cartão Qualquer acesso físico aos dados ou sistemas que abrigam os dados do portador de cartão cria uma oportunidade para que indivíduos possam ter acesso aos dispositivos ou dados e remover sistemas ou cópias físicas e, portanto, devem ser devidamente restritos.

Exigência Diretriz

9.1 Usar os controles adequados para a admissão nas instalações, limitar e controlar o acesso físico aos sistemas que armazenam, processam ou transmitem os dados do portador de cartão.

Sem os controles ao acesso físico, pessoas não autorizadas podem ter acesso às instalações e à informação confidencial e podem alterar as configurações do sistema, introduzir vulnerabilidades na rede, ou destruir ou roubar equipamentos.

9.1.1 Usar câmaras para monitorar as áreas críticas. Realizar a auditoria dos dados coletados e fazer a correlação com outras entradas. Armazenar estes dados por pelo menos três meses, a menos que proibido por lei.

Sem estar alerta em relação aos sistemas críticos, as invasões físicas serão difíceis de prevenir e investigar e os atacantes não poderão ser identificados.

9.1.2 Restringir o acesso físico às tomadas de acesso público à rede.

Restringir acesso às tomadas da rede irá evitar que os hackers se conectem através das mesmas às redes disponíveis e que permitem que tenham acesso aos recursos da rede interna. Considere desligar estas tomadas de rede quando não em uso e reativá-las apenas quando necessário. Nas áreas públicas, tais como salas de conferência, estabelecer redes privadas que permitam aos fornecedores e visitantes acessar a Internet de forma a que eles não estejam conectados à rede interna.

9.1.3 Restringir o acesso físico aos pontos de acesso para wireless, portais e dispositivos portáteis.

Sem segurança sobre o acesso aos componentes e dispositivos wireless, usuários mal intencionados podem usar os dispositivos wireless desassistidos da organização para ter acesso aos recursos da sua rede, ou mesmo conectar os seus próprios dispositivos à sua rede wireless, dando a eles um acesso não autorizado. Considere colocar os pontos de acesso wireless e gateways em áreas de armazenagem seguras, tais como em compartimentos trancados. Assegure-se de que esteja habilitada uma forte codificação e um dispositivo automático de bloqueio de aparelhos portáteis após um período de inatividade e configure estes equipamentos para exigirem uma senha ao serem ligados.


Exigência Diretriz

9.2 Desenvolver procedimentos para auxiliar os funcionários a distinguir entre funcionários e visitantes, especialmente nas áreas onde os dados do portador de cartão podem ser acessados. “Funcionário” é definido como empregados de meio expediente e tempo integral, temporários, estagiários e consultores que são “residentes” na instalação da empresa. Um “visitante” é definido como um fornecedor, prestador de serviço, convidado de um funcionário, pessoal de manutenção e serviço ou qualquer um que necessite entrar nas instalações por um curto período de tempo, geralmente por não mais do que um dia.

Sem um sistema de crachás e controladores de portas, usuários não autorizados e insidiosos podem facilmente ter acesso às instalações e roubar, desativar, interferir ou destruir sistemas importantes e os dados do portador de cartão. Para um controle eficiente, considere a implantação de um sistema de crachás ou cartão de acesso para a entrada ou saída de uma área de trabalho que contenha os dados do portador de cartão.

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

O registro (log) de visitantes é importante para reduzir a habilidade de pessoas não autorizadas ou maliciosas de terem acesso às suas instalações (e potencialmente, aos dados do portador de cartão).

9.3.1 Sejam autorizados antes de entrar nas áreas onde os dados do portador de cartão são processados ou mantidos.

9.3.2 Recebam uma identificação física (por exemplo, um crachá ou dispositivo de acesso) que tenha vencimento e que identifique os visitantes como não funcionários.

9.3.3 Sejam solicitados a retornar a identificação física antes de deixar a instalação ou por ocasião do vencimento.

O registro de visitantes é importante para assegurar que os mesmos tenham acesso apenas às áreas às quais estão autorizados, que eles sejam identificáveis como visitantes para que os funcionários possam monitorar suas atividades e que seu acesso seja restrito apenas durante a duração de suas legítimas visitas.

9.4 Usar um registro (log) de visitantes para manter uma evidência física das atividades dos mesmos com a finalidade de auditoria. Manter este registro por no mínimo três meses, a menos que proibido por lei.

Um registro de visitantes é barato e fácil de manter e irá ajudar durante a investigação de uma potencial quebra da segurança de dados, através da identificação do acesso físico às instalações ou sala e acesso potencial aos dados do portador de cartão. Considere a implementação de registros de entrada às instalações e especialmente nas zonas onde os dados do portador de cartão estejam presentes.


Exigência Diretriz

9.5 Armazenar a mídia de backups em um local seguro, de preferência fora das instalações, tal como um local alternativo, de backup ou uma instalação comercial de armazenamento.

Os backups podem conter os dados do portador de cartão e, se armazenados em uma instalação não segura, podem ser facilmente perdidos ou roubados e copiados com intenção maliciosa. Para a armazenagem segura, considere a contratação de uma organização comercial de armazenagem de dados OU, de uma pequena entidade usando um cofre.

9.6 Exercer a segurança física de toda a mídia em papel e eletrônica (incluindo computadores, mídia eletrônica, hardware de rede e comunicação, linhas de telecomunicação, recibos em papel, relatórios em papel e faxes) que contenham os dados do portador de cartão.

Os dados do portador de cartão estão sujeitos a serem vistos, copiados ou “escaneados” de forma não autorizada se estiverem desprotegidos quando em uma mídia portátil, impressos ou deixados na mesa de alguém. Considere os procedimento e processos para a proteção dos dados do portador de cartão nas mídias distribuídas aos usuários internos ou externos. Sem tais procedimentos o dado pode ser perdido ou roubado e usado com propósitos fraudulentos.

9.7 Manter um controle rigoroso sobre a distribuição interna ou externa de qualquer tipo de mídia que contenha os dados do portador de cartão incluindo o seguinte:

9.7.1 Classificar a mídia de forma que a mesma possa ser identificada como confidencial.

A mídia não identificada como confidencial pode deixar de ser tratada com o cuidado que ela requer e pode ser perdida ou roubada. Incluir um processo ou procedimentos de classificação da mídia conforme recomendado na exigência 9.6 acima.

9.7.2 Enviar a mídia por intermédio de um mensageiro seguro ou um mecanismo de entrega que possa ser acompanhado de forma precisa.

A mídia pode ser perdida ou roubada se enviada por intermédio de um método que não possa ser monitorado, tal como os serviços regulares dos correios postais. Contrate um serviço de courier de segurança para a entrega de qualquer mídia que contenha os dados do portador de cartão, de forma a que os seus sistemas de acompanhamento possam ser usados para manter um inventário e localizar as remessa.

9.8 Obter a aprovação da administração para toda e qualquer mídia que seja transportada para fora da área de segurança (especialmente quando a mídia for distribuída para indivíduos).

Se os dados do portador de cartão deixarem as áreas seguras sem um processo aprovado pela administração, pode ocorrer a perda ou roubo dos mesmos. Sem um processo firme, a localização da mídia não pode ser monitorada, nem existe um processo para saber para onde o dado foi enviado e de como está protegido. Incluir um processo de desenvolvimento aprovado pela administração para mover a mídia conforme recomendado na exigência 9.6 acima.


Exigência Diretriz

9.9 Manter um controle rigoroso sobre a armazenagem e acesso à mídia que contenha as informações do portador de cartão.

Sem métodos cuidadosos de controle de inventário e armazenagem, o roubo ou perda da mídia pode não ser notado por um tempo indefinido. Incluir o desenvolvimento de um processo para limitar o acesso à mídia contendo os dados do portador de cartão de acordo com os procedimentos dos itens recomendados na exigência 9.6 acima.

9.9.1 Fazer um inventário rigoroso de toda a mídia e certificar-se de que a mesma está armazenada de forma segura.

Se a mídia não for objeto de um inventário, a perda ou roubo pode não ser notada por um longo prazo. Incluir o desenvolvimento de um processo para o inventário da mídia e armazenagem seguro conforme os procedimentos de armazenagem recomendada na exigência 9.6 acima.

9.10 Destruir a mídia contendo os dados do portador de cartão quando não for mais necessária para o negócio ou por razões legais como a seguir:

Se não forem tomados os passos para destruir a informação contida nas unidades de disco dos PCs e CDs e em papel, a disposição de tal informação pode resultar no comprometimento e levar a prejuízos financeiros e perda de reputação. Por exemplo, os hackers podem usar a técnica conhecida como “dumpster diving”, onde eles fazem buscas através das latas de lixo e caixas de reciclagem e usam a informação encontrada para lançar um ataque. Incluir o desenvolvimento de um processo para destruir apropriadamente a mídia contendo os dados do portador de cartão, incluindo a própria armazenagem de tal mídia antes da destruição conforme o recomendado na exigência 9.6 acima.

9.10.1 Cortar no sentido cruzado com picador de papel, incinerar ou reduzir à polpa os materiais de cópia física.

9.10.2 Purgar, neutralizar o campo magnético através do processo de degauss, picotar ou destruir de outra forma a mídia eletrônica de maneira a que os dados do portador de cartão não possam ser reconstruídos.


Diretrizes para as Exigências 10 e 11: Acompanhar e Testar Regularmente as Redes

Exigência 10: Acompanhar e monitorar todo o acesso aos recursos da rede e dados do portador de cartão Os mecanismos de registro (logs) e a habilidade de acompanhar as atividades do usuário são fundamentais. A presença dos logs em todos os ambientes permite o acompanhamento preciso e a análise quando algo de errado acontece. A determinação da causa de um comprometimento se torna muito difícil sem o registro de atividades.

Exigência Diretriz

10.1 Estabelecer um processo para vincular todo o acesso aos componentes do sistema (especialmente os acessos feitos com privilégios administrativos, tais como raiz (root)) para um usuário individual.

É importante haver um processo ou sistema que conecte o acesso do usuário aos componentes do sistema de acesso e em particular, para aqueles usuários que possuem privilégios administrativos. Este sistema gera um registro de auditoria e oferece a habilidade para traçar de volta as atividades suspeitas a um usuário específico. As equipes que examinam os incidentes depois de ocorridos (forensics teams) dependem fortemente destes registros para iniciar a investigação.

10.2 Implementar os registros de auditoria automatizados em todos os componentes do sistema para reconstruir eventos a seguir, para todos os componentes do sistema: 10.2.1 Todo acesso feito por um usuário individual

aos dados do portador de cartão. 10.2.2 Todas as ações tomadas por qualquer

indivíduo com privilégios tipo “root” ou administrativos.

10.2.3 Acesso a todos os registros de auditoria. 10.2.4 Tentativas inválidas de acesso lógico. 10.2.5 Uso de mecanismos de identificação e

autenticação. 10.2.6 Inicialização dos logs de auditoria. 10.2.7 Criação ou eliminação de objetos ao nível de

sistema.

Os hackers em uma rede irão geralmente tentar múltiplos acessos aos sistemas alvo. A geração de registros da auditoria das atividades suspeitas alerta o administrador do sistema, envia o dado a outros mecanismos de monitoramento (tais como os sistemas de detecção de intrusão) e oferece um registro histórico para o acompanhamento pós-incidente.


Exigência Diretriz 10.3 Gravar pelo menos os seguintes registros de

auditoria em todos os componentes do sistema para cada evento ligado a todos os componentes do sistema:

10.3.1 Identificação do usuário. 10.3.2 Tipo de evento. 10.3.3 Data e hora. 10.3.4 Indicação de sucesso ou falha. 10.3.5 Origem do evento. 10.3.6 Identidade ou nome do dado, componente

de sistema ou recurso afetado.

Com o registro destas entradas para eventos auditáveis da exigência 10.2, um potencial comprometimento pode ser rapidamente identificado e com detalhes suficientes para saber quem, o que, onde e como.

10.4 Sincronizar todos os relógios e datas de todos os sistemas críticos.

Se um hacker tiver entrado na rede, geralmente vai tentar mudar a data e hora (time stamps) das suas ações nos registros de auditoria para evitar a detecção das suas atividades. Para as equipes que examinam os incidentes depois de ocorridos (forensics teams), a hora de cada atividade é importante para determinar como os sistemas foram comprometidos. Um hacker pode também tentar mudar diretamente o relógio em um servidor de hora (time server), se as restrições ao acesso não forem apropriadas, para mudar a hora para o período anterior à entrada do hacker na rede.

10.5 Tornar seguros os registros de auditoria para que eles não possam ser alterados.

Geralmente um hacker que tenha entrado na rede tentará editar os registros de auditoria para esconder suas atividades. Sem uma proteção adequada destes registros, a sua qualidade, precisão e integridade não podem ser garantidas e podem se tornar inúteis como uma ferramenta de investigação após um comprometimento.


Exigência Diretriz

10.5.1 Limitar o acesso aos registros de auditoria àqueles que tenham necessidade relacionada com o trabalho.

10.5.2 Proteger os arquivos contendo os registros de auditoria contra modificações não autorizadas.

10.5.3 Fazer o backup imediato dos arquivos contendo os registros de auditoria em um servidor centralizado de logs ou mídia que seja difícil de alterar.

10.5.4 Copiar os logs das redes wireless em um servidor de registro na LAN interna.

A proteção adequada dos registros de auditoria inclui um forte controle ao acesso (limitar o acesso ao registros (logs) baseado apenas na necessidade de saber (need to know) e uso de segregação interna (intern segregation) para tornar os registros difíceis de serem encontrados e modificados).

10.5.5 Usar um software de acompanhamento e detecção de mudanças na integridade de arquivos para assegurar que os dados dos registros existentes não possam ser alterados sem causar alertas (embora a adição de um novo dado não deva causar um alerta).

O sistemas de acompanhamento da integridade do arquivo verificam a ocorrência de mudanças nos arquivos mais importantes e emitem uma notificação quando são notadas alterações. Para os propósitos de acompanhamento da integridade, uma organização geralmente monitora os arquivos que não mudam com regularidade, mas quando alterados, indicam a possibilidade de um possível comprometimento. Para os arquivos de registro “log files” (que mudam freqüentemente), o que deve ser monitorado são, por exemplo, quando o arquivo foi apagado, crescimento ou diminuição significativa e qualquer outro indicador de que um hacker tenha entrado no arquivo de registro. Existem várias ferramentas (off-the-shelf e open source) disponíveis para o acompanhamento da integridade de arquivos.

10.6 Revisar os logs de todos os componentes do sistema pelo menos diariamente. As revisões dos logs devem incluir os servidores que executam funções de segurança tais como intrusion detection system (I DS) e servidores de authentication, authorization, and accounting protocol (AAA) (por exemplo, RADIUS). Nota: Ferramentas de alerta, armazenamento e análise podem ser usadas para estar em conformidade com a exigência 10.6.

Muitas quebras do sigilo ou invasões podem ocorrer durante dias ou meses antes de serem detectadas. O acompanhamento diário dos registros pode minimizar o período de tempo e exposição a uma invasão eventual. O processamento da revisão dos registros não tem que ser manual. Especialmente para aquelas organizações que possuem um grande número de servidores, deve ser considerado o uso de ferramentas de alerta, “log harvesting” e “parsing”.


Exigência Diretriz

10.7 Manter os seus registros de auditoria por um período de pelo menos um ano, com uma disponibilidade mínima de três meses.

Os registros devem ser retidos por pelo menos um ano tendo em vista que geralmente leva tempo para perceber que ocorreu ou está ocorrendo um comprometimento e permitir que os investigadores tenham um histórico longo o suficiente para determinar o período de duração do ataque potencial e seus possíveis impactos nos sistemas.


Exigência 11: Testar regularmente os sistemas e os processos de segurança As vulnerabilidades são continuamente descobertas por hackers e pesquisadores ou sendo introduzidas por novos softwares. Os sistemas, processos e softwares customizados devem ser testados freqüentemente para se certificar de que a segurança está sendo mantida ao longo do tempo e sempre que haja quaisquer mudanças em software.

Exigência Diretriz

11.1 (a) Fazer anualmente os testes dos controles de segurança, das limitações, das conexões com a rede e das restrições de forma contínua, para se certificar da habilidade de adequadamente poder identificar e bloquear quaisquer tentativas de acesso não autorizado.

Se não houver um teste consistente, podem ocorrer falhas nos controles de segurança que podem ser subseqüentemente explorados.

(b) Usar um analisador de wireless pelo menos trimestralmente para identificar todos os dispositivos wireless em uso.

A implementação e/ou utilização da tecnologia wireless dentro de uma rede é uma dos caminhos mais comuns para que os usuários mal intencionados obtenham acesso à rede e dados do portador de cartão. Se um dispositivo wireless ou de rede for instalado sem o conhecimento da organização, ele pode permitir que um hacker entre na rede de forma fácil e imperceptível. Adicionalmente podem ser usados um analisador de wireless “nmap” e outras ferramentas de rede para detectar os dispositivos wireless que podem ser usados.

11.2 Executar scans para testar a vulnerabilidade interna e externa da rede pelo menos a cada trimestre ou após qualquer mudança significativa na rede (tais como, instalação de um novo componente de sistema, mudanças na topologia da rede, modificações na regra do firewall, upgrades de produtos). Nota: Os scans de vulnerabilidade externa devem ser executados trimestralmente por um prestador de serviço de scan qualificado pela indústria de cartões de pagamentos. Os scans conduzidos depois das mudanças na rede podem ser executados pelo pessoal interno da companhia.

O scan de vulnerabilidade é uma ferramenta automatizada que roda contra os pontos de acesso externos e internos da rede e dispositivos e servidores, para expor as potenciais vulnerabilidades e identificar os ports nas redes que podem ser descobertos e utilizados pelos hackers. Uma vez que esta debilidade seja identificada, a organização a corrige e torna a rede mais segura.


Exigência Diretriz

11.3 Executar um teste de penetração pelo menos uma vez por ano e após qualquer modificação ou upgrade significativo da infra-estrutura ou aplicativo (tal como, um upgrade do sistema operacional, uma adição de uma sub-rede no ambiente, adição de um servidor de web no ambiente). Estes testes de penetração devem incluir o seguinte:

11.3.1 Testes de penetração network-layer. 11.3.2 Testes de penetração application-layer.

Os testes de penetração da rede e aplicativos são diferentes dos scans de vulnerabilidade visto que os testes de penetração são mais manuais, tentam utilizar algumas das vulnerabilidades identificadas nos scans e seguir as práticas usadas pelos hackers para tirar vantagem das fraquezas dos sistemas e processos. Antes dos aplicativos, dispositivos de rede e sistemas serem liberados para produção, eles devem ser fortalecidos e tornados seguros usando as melhores práticas (pela exigência 2.2). Os scans de vulnerabilidade e testes de penetração irão expor quaisquer vulnerabilidades restantes que mais tarde podem ser encontradas e utilizadas pelos hackers.

11.4 (a) Usar sistemas de detecção de intrusão na rede, sistemas de detecção baseado em host e sistemas de prevenção de intrusão para acompanhar todo o tráfego na rede e alertar os funcionários para comprometimentos suspeitos.

Estas ferramentas comparam o tráfego vindo para a rede com as “assinaturas” conhecidas de milhares de tipos (hacker tools, Trojans, etc.) e enviam alertas e/ou param a tentativa na medida em que ela acontece. Sem uma abordagem proativa ou detecção da atividade não autorizada por intermédio destas ferramentas, os ataques aos (ou mau uso) recursos do computador podem não ser notados em tempo real. Os alertas de segurança gerados por estas ferramentas devem se monitorados, de forma a que as tentativas de invasão possam ser neutralizadas.

(b) Manter atualizados todos os sistemas de detecção e prevenção.

Existem milhares de tipos de comprometimento, e mais e mais está sendo descoberto a cada dia. As versões não atualizadas destes sistemas não irão possuir as “assinaturas” mais recentes e não irão identificar as novas vulnerabilidades que podem levar a uma invasão despercebida. Os fornecedores destes produtos oferecem atualizações freqüentes, geralmente diárias.


Exigência Diretriz 11.5 Instalar o software de acompanhamento da integridade

de arquivos para alertar os funcionários sobre uma modificação não autorizada de sistemas críticos ou conteúdo de arquivos e configure o software para executar as comparações dos arquivos críticos pelo menos semanalmente. Os arquivos críticos não são necessariamente apenas aqueles que contêm os dados do portador de cartão. Com relação ao acompanhamento da integridade dos arquivos críticos, são considerados geralmente arquivos críticos aqueles que não mudam regularmente, mas a modificação pode indicar um comprometimento ou risco de comprometimento do sistema. Os produtos de acompanhamento da integridade de arquivo geralmente vêm pré-configurados com arquivos críticos para o sistema operacional relacionado. Outros arquivos críticos, tais como aqueles de aplicativos customizados, devem ser avaliados e definidos pela organização (que é o estabelecimento ou prestador de serviços).

Os sistemas de monitoramento da integridade dos arquivos verificam as mudanças em files críticos e notificam quando tais mudanças são notadas. Existem várias ferramentas (off-the-shelf e open source) disponíveis para o acompanhamento da integridade de arquivos. Se não forem implementados e o output acompanhado, um hacker ou usuário com más intenções pode alterar o conteúdo do arquivo ou roubar o dado de forma não detectada.


Diretrizes para a Exigência 12: Manter uma Política de Segurança da Informação

Exigência 12: Manter uma política que atenda à segurança da informação para funcionários e prestadores de serviços Uma política rigorosa de segurança cria um exemplo para toda a empresa e informa aos funcionários o que é esperado deles. Todos os funcionários devem estar cientes do cuidado a ser aplicado aos dados e suas responsabilidades em protegê-los.

Exigência Diretriz

12.1 Estabelecer, divulgar, manter e disseminar uma política de segurança que objetive o seguinte: 12.1.1 Atender a todas as exigências contidas nesta

especificação. 12.1.2 Incluir um processo anual que identifique

ameaças e vulnerabilidades e resulte em um levantamento do risco formal.

12.1.3 Incluir pelo menos uma revisão anual e updates quando houver mudanças no ambiente.

A política de informação de uma organização cria o caminho para a implementação de medidas de segurança ao proteger o seu patrimônio mais precioso. Uma forte política de segurança dá o exemplo para toda a organização e deixa os funcionários saberem que o que é esperado deles. Todos os funcionários devem estar alerta sobre a sensibilidade do dado e suas responsabilidades para protegê-lo. As ameaças à segurança e métodos de proteção evoluem rapidamente durante um ano. Sem a atualização da política de segurança para refletir estas mudanças, não existirão medidas para lutar contra estas ameaças.

12.2 Desenvolver procedimentos diários de segurança operacional que sejam consistentes com as exigências desta especificação (por exemplo, procedimentos de manutenção da conta do usuário e procedimentos de revisão do log).

Os procedimentos de segurança operacional diária atuam como instruções (desk instructions) para serem usadas pelos funcionários nas atividades de manutenção diária do seu sistema administrativo. Procedimentos de segurança operacional não documentados irão fazer com que os funcionários não fiquem atualizados sobre o alcance total de suas tarefas, processos que não podem ser facilmente repetidos pelos novos funcionários e aberturas potenciais nestes processos que pode permitir que um hacker tenha acesso a sistemas e recursos importantes.


Exigência Diretriz

12.3 Desenvolver políticas definindo o uso por funcionários que lidam com tecnologias críticas (tais como modems e wireless) para definir o uso apropriado destas tecnologias para todos os funcionários e prestadores de serviços. Certificar-se que estas políticas de uso exigem o seguinte:

As políticas de uso pelo funcionário tanto podem proibir o uso de determinados dispositivos caso seja a política da organização, ou oferecerem uma diretriz para o uso e implementação de uma forma correta. Se as políticas de uso não estivem implantadas, os funcionários podem usar dispositivos que violem a política da organização, podem sem saber, configurar modems e/ou redes wireless sem segurança e portanto permitir que os hackers tenham acesso a sistemas importantes e aos dados do portador de cartão. Para assegurar que os padrões da organização sejam seguidos e sejam implementadas apenas as tecnologias aprovadas, considere restringir a implementação apenas às equipes de operações. Não permita que funcionários não especializados instalem estas tecnologias.

12.3.1 Aprovação explícita pela administração. Sem solicitar a devida autorização pela administração para a implementação destas tecnologias, um funcionário pode inocentemente implantar uma solução para atender a uma necessidade perceptível da organização, mas também abrir um imenso espaço que expõe os sistemas importantes e os dados aos hackers.

12.3.2 Autenticação para o uso da tecnologia. Se esta tecnologia for implementada sem a devida autenticação (ID de usuários e senhas, tokens, VPNs, etc.), os hackers podem usar facilmente esta tecnologia desprotegida para ter acesso a sistemas críticos e dados do portador de cartão.

12.3.3 Uma lista de todos os dispositivos e funcionários com acesso.

Os hackers podem quebrar a segurança física e colocar seus próprios dispositivos na rede como uma porta de entrada pelos fundos (back door). Os funcionários podem também fazer um procedimento de “bypass” e instalar dispositivos. Um inventário minucioso com a etiquetagem apropriada dos dispositivos permite uma rápida identificação das instalações não aprovadas. Considere estabelecer uma convenção de nomenclatura oficial para os dispositivos e etiquetar e registrar todos os dispositivos de acordo com os controles de inventários estabelecidos.

12.3.4 Etiquetagem dos dispositivos com indicação do proprietário, informação de contato e objetivo.

12.3.5 Uso aceitável da tecnologia. Ao definir o uso aceitável para o negócio e localização aceitável dos dispositivos e tecnologias aprovados pela organização, esta poderá administrar e controlar os espaços nas configurações e controles operacionais, ao assegurar que a posta dos fundos não se encontra aberta por um hacker para ter acesso aos sistemas críticos e dados do portador de cartão.

12.3.6 Localização aceitável da rede para estas tecnologias.

12.3.7 Uma lista de produtos aprovados pela empresa.

12.3.8 Desligamento automático da sessão com Os modems são uma freqüente "porta dos fundos" para recursos importantes


Exigência Diretriz modem após um período de inatividade específico.

e dados do portador de cartão. Ao desconectar os modems quando não estiverem em uso (por exemplo, aqueles usados para dar suporte aos sistemas pelo seus fornecedores de POS ou outros), é minimizado o acesso e risco às redes. Considere o uso de controles padrão de modem ao desconectar os dispositivos após 15 minutos de inatividade. Favor também consultar a exigência 8.5.6 para obter maiores informações sobre este tópico.

12.3.9 Ativação dos modems para os prestadores de serviço apenas quando for necessário, com imediata desativação após o uso.

12.3.10 Proibição da armazenagem de dados do portador de cartão nas unidades de disco locais, floppy disks ou outra mídia externa quando os dados do portador de cartão forem acessados remotamente via modem. Também proibir as funções “cut and paste” e “print” durante o acesso remoto.

Ao se assegurar que seus funcionários estão cientes das suas responsabilidades em não armazenar ou copiar os dados do portador de cartão em seu computador pessoal local ou outra mídia, a sua organização deve possuir uma política que proíba claramente estas atividades.

12.4 Assegurar-se de que a política de segurança e procedimentos defina claramente as responsabilidades de segurança da informação para todos os funcionários e prestadores de serviço.

Sem atividades claramente definidas e responsabilidades atribuídas, pode haver uma interação inconsistente com o grupo de segurança, levando à implementação de tecnologias inseguras ou o uso de versões ultrapassadas ou inseguras.

12.5 Delegar as seguintes responsabilidades de administração de segurança da informação para um indivíduo ou equipe: 12.5.1 Implementar, documentar e distribuir os

procedimentos da política de segurança e regulamentos.

12.5.2 Acompanhar e analisar os alertas de segurança e informação e distribuí-los ao pessoal apropriado.

12.5.3 Implementar, documentar e distribuir os procedimentos de resposta a um incidente de segurança e escalonamento para assegurar a administração oportuna e eficiente de todas as situações.

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

12.5.5 Acompanhar e controlar todo o acesso aos dados.

Cada pessoa ou equipe com responsabilidades pela administração da segurança da informação deve estar claramente consciente dos seus deveres e tarefas relacionadas, através de política específica. Sem esta responsabilidade, pode ser criado um acesso a recursos importantes ou dados do portador de cartão.


Exigência Diretriz

12.6 Implementar um programa formal de conscientização da segurança para fazer com que todos os funcionários estejam cientes da importância atribuída à segurança dos dados do portador de cartão.

Se os usuários não forem treinados sobre as suas responsabilidades de segurança, as proteções e processos que foram implementados podem se tornar ineficientes através de erros dos funcionários ou ações intencionais.

12.6.1 Treinar os funcionários após a contratação e pelo menos uma vez por ano (por exemplo, através de cartas, posters, memorandos, reuniões e promoções).

Se o programa de conscientização sobre segurança não incluir sessões de atualização anual, os processos e procedimentos de segurança importantes podem ser esquecidos ou ignorados, resultando na exposição de recursos críticos e dados do portador de cartão.

12.6.2 Exigir que os funcionários reconheçam por escrito que eles leram e entenderam a política e procedimentos de segurança da empresa.

Exigir a assinatura de um funcionário ajuda a assegurar de que eles leram e entenderam os procedimentos e políticas de segurança e que os mesmos se comprometeram a obedecer estas políticas.

12.7 Investigar os funcionários potenciais para minimizar o risco de ataques com origem em fontes internas. Para aqueles funcionários, tais como caixas de lojas, que apenas possuem acesso a um número de conta de cartão de cada vez ao executar uma transação, esta exigência é apenas uma recomendação.

Efetuar uma investigação completa dos antecedentes e conduta dos funcionários que tiverem acesso aos dados do portador de cartão reduz o risco do uso não autorizado dos números das contas por indivíduos com passado questionável ou criminoso. É esperado que a organização possua uma política e procedimento com relação ao levantamento das informações criminais, incluindo a sua própria política sobre que resultados do levantamento terão um impacto nas suas decisões de contratação (e qual seria o impacto).

12.8 Se os dados do portador de cartão forem compartilhados com o prestador de serviço, então o seguinte é exigido contratualmente:

12.8.1 Os provedores de serviço devem cumprir com as exigências do PCI DSS.

12.8.2 Acordo que inclua uma confirmação de que o provedor de serviço é responsável pela segurança dos dados do portador de cartão que o mesmo possuir.

Se um estabelecimento ou prestador de serviço compartilha os dados do portador de cartão com um prestador de serviço, então o prestador de serviço que receber estes dados deve assinar um documento legal que o torne responsável pelo cumprimento das exigências de segurança referentes aos mesmos, aceitando suas responsabilidades. Isto ajuda a assegurar que a proteção continuada a estes dados serão executadas pelas partes externas.


Exigência Diretriz

12.9 Implementar um plano de resposta a um incidente. Esteja preparado para responder imediatamente a uma quebra da segurança do sistema.

12.9.1 (a) Criar um plano de resposta a um incidente para ser usado no evento do comprometimento do sistema.

Sem um plano completo de resposta a incidente de segurança que seja devidamente divulgado, lido e entendido pelas partes responsáveis, a confusão e falta de resposta unificada pode criar maior tempo fora de operação (downtime) para o negócio, maior exposição desnecessária à imprensa pública, bem como responsabilidades legais.

(b) Assegurar-se de que o plano atende, pelo menos, aos procedimentos de resposta específicos, processos de recuperação de negócios e continuidade, processos de backup dos dados, desempenho e responsabilidades e estratégias de comunicação e contato (por exemplo, informar os Adquirentes e associações de cartões de crédito).

O plano de resposta a incidente deve ser completo e conter todos os principais elementos que permitam à organização responder eficientemente na hipótese de ocorrer uma violação que possa causar impacto sobre os dados do portador de cartão.

12.9.2 Testar o plano pelo menos uma vez por ano. Sem o teste apropriado, podem ser ignorados passos importantes capazes de limitar a exposição em caso de um incidente.

12.9.3 Designar funcionários específicos para estarem disponíveis numa base de 24/7 para responder aos alertas.

Sem uma equipe de resposta a incidente treinada e imediatamente disponível, pode ocorrer danos extensivos à rede e dados críticos e sistemas podem se tornar “poluídos” por manuseio inapropriado dos sistemas alvo. Isto pode afetar negativamente o sucesso da investigação pós-incidente. Se os recursos internos não estiverem disponíveis, considere a contratação de um prestador de serviços que execute estes serviços.

12.9.4 Fazer o treinamento apropriado dos funcionários em termos das responsabilidades pela resposta a uma quebra de segurança.

12.9.5 Incluir alertas originários da detecção de uma intrusão, prevenção de intrusão e sistemas de acompanhamento da integridade dos arquivos.

Estes sistemas de acompanhamento são desenhados para se focalizar no risco potencial aos dados e são fundamentais para a rápida tomada de ação para prevenir um ataque. Assegure-se de que os sistemas de monitoramento estão incluídos nos processos de resposta a incidentes.

12.9.6 Criar um processo para modificar e desenvolver o plano de resposta a um incidente de acordo com as lições aprendidas e incorporar os desenvolvimentos da indústria.

A incorporação das “lições aprendidas” no plano de resposta a incidente após um incidente ajuda a manter o plano atualizado e capaz de reagir às tendências de segurança.


Exigência Diretriz

12.10 Todos os processadores e prestadores de serviço devem manter e implementar políticas e procedimentos para administrar entidades conectadas que incluam o seguinte:

Uma “entidade conectada (connected entity) é qualquer entidade que esteja "upstream" e conectada a um processador ou prestador de serviço com o propósito de receber os dados do portador de cartão, incluindo os agentes processadores, agentes, organização de venda ou outro prestador de serviços. Esta definição de "connected entities" não inclui as entidades "downstream" tais como estabelecimentos e outros prestadores de serviços e processadores que originaram os dados e estão agora os recebendo de volta da entidade em questão. Ao administrar estas entidades conectadas de forma eficiente, os processadores e prestadores de serviços devem possuir políticas para guiá-los.

12.10.1. Manter uma lista das entidades conectadas.

Uma lista de inventário das entidades conectadas deve ser mantida para prover a informação sobre cada conexão e ajudar no troubleshoot, se necessário.

12.10.2. Garantir que são tomadas as providências adequadas antes da conexão de uma entidade.

A política deve incluir o devido processo de diligência, de acordo com o processo que for considerado necessário pela organização.

12.10.3. Garantir que a entidade cumpre com o PCI DSS.

O objetivo desta ação é atendido se a organização possuir um contrato com a entidade conectada, conforme a exigência 12.8.1 acima.

12.10.4. Conectar e desconectar entidades seguindo um processo estabelecido.

A política deve incluir uma listagem dos passos a serem seguidos para os processos de conexão e desconexão.


Diretrizes para a Exigência A.1: Aplicação do PCI DSS aos Prestadores de Serviço de Host

Exigência A.1: Prestadores do serviço de host devem proteger o ambiente de dados do portador de cartão De acordo com o mencionado na Exigência 12.8, todos os prestadores de serviço com acesso aos dados do portador de cartão (incluindo os provedores do serviço de hosting) têm que cumprir com o PCI DSS. Adicionalmente, a Exigência 2.4 declara que os prestadores do serviço de hosting devem proteger o ambiente e os dados “hosted” pela entidade. Conseqüentemente, os prestadores do serviço de hosting devem levar em consideração especialmente o seguinte: Exigência Diretriz

A.1 Proteger o ambiente e os dados cada entidade (ou seja, do estabelecimento, do provedor de serviço ou de outra entidade) hosted, de modo a incluir as exigências de A.1.1 até A.1.4 abaixo:

O Anexo A do PCI DSS é direcionado para os provedores de hosting compartilhado que desejam oferecer aos seus estabelecimentos e/ou prestadores de serviço clientes um ambiente de hosting em conformidade com o PCI DSS. Estes passos devem ser cumpridos, em adição a todos as outras exigências relevantes do PCI DSS.

A.1.1 Assegurar que cada entidade tenha acesso apenas ao ambiente dos dados do seu portador de cartão.

Se um estabelecimento ou prestador de serviço tiver permissão para rodar os seus próprios aplicativos em um servidor compartilhado, ele deve fazê-lo com um ID de usuário do estabelecimento ou prestador de serviço, ao invés de um usuário privilegiado. Um usuário privilegiado teria acesso ao ambiente de dados do portador de cartão de todos os outros estabelecimentos e prestadores de serviços bem como aos seus próprios.

A.1.2 Restringir o acesso e privilégios de cada entidade apenas ao ambiente de dados do seu portador de cartão.

Ao certificar-se de que o acesso e privilégios estão restritos de forma a que cada estabelecimento ou prestador de serviço possua acesso apenas ao seu próprio ambiente de dados do portador de cartão, considere o seguinte: 1) ID de usuário do servidor de web do estabelecimento ou prestador de serviços privilegiado, 2) permissões deferidas para ler, escrever e executar arquivos, 3) permissões garantidas para escrever nos binários do sistema, 4) permissões deferidas aos arquivos de registro dos estabelecimentos e prestadores de serviços e 5) controles para certificar-se de que um estabelecimento ou prestador de serviço não pode monopolizar os recursos do sistema.

A.1.3 Assegurar que os acompanhamentos de log-in e auditoria estão habilitados e são únicos para o ambiente de dados do portador de cartão de cada entidade e consistentes com a Exigência 10 do PCI DSS.

Os registros devem estar disponíveis em um ambiente de hosting compartilhado, de forma a que os estabelecimentos e prestadores de serviços tenham acesso e possam fazer a revisão dos mesmos desde que sejam específicos ao seu ambiente de dados do portador de cartão.

A.1.4 Habilitar processos que facilitem o mais Os provedores de hosting compartilhados devem habilitar um processo para


Exigência Diretriz rápido possível as investigações do evento de um comprometimento em algum estabelecimento ou provedor de serviço hosted.

dar uma resposta rápida e fácil no evento de ser necessário uma investigação sobre um comprometimento, no nível apropriado de detalhes de forma a que os mesmos pertencentes ao estabelecimento ou prestador de serviço individual estejam disponíveis.


Anexo A: Padrão de Segurança de Dados PCI: Documentos Relacionados

Os seguintes documentos foram criados para auxiliar os estabelecimentos e prestadores de serviços a conhecerem melhor o Padrão de Segurança de Dados PCI e o PCI DSS SAQ.

Documento Público Alvo

Padrão de Segurança de Dados PCI Todos os estabelecimentos e prestadores de serviços

Navegando o PCI DSS: Entendendo a Razão das Exigências Todos os estabelecimentos e prestadores de serviços

Padrão de Segurança de Dados PCI: Instruções e Diretrizes da Auto-avaliação, Todos os estabelecimentos e prestadores de serviços

Padrão de Segurança de Dados PCI: Questionário de Auto-avaliação A e Declaração

Prestadores de serviços 1

Padrão de Segurança de Dados PCI: Questionário de Auto-avaliação B e Declaração


Padrão de Segurança de Dados PCI: Questionário de Auto-avaliação C e Declaração


Padrão de Segurança de Dados PCI: Questionário de Auto-avaliação A e Declaração

Prestadores de serviços e todos os outros estabelecimentos 9

Padrão de Segurança de Dados PCI: Glossário, Abreviações e Acrônimos Todos os estabelecimentos e prestadores de serviços

9 Para determinar qual é o Questionário de Auto-avaliação adequado, consulte o Padrão de Segurança de Dados: Instruções e Diretrizes para a

Auto-avaliação, “Selecionando o SAQ e a Declaração Que Melhor se Adapta à Sua Organização.”

navegando o pci dss...de cartão. o ambiente de dados do portador de cartão é aquela parte da rede...

Documents