Conhecer a intenção dos requisitos

Transcrição

1 Indústria de cartões de débito (PCI - Payment Card Industry) Padrão de segurança dos dados Navegando pelo PCI DSS Conhecer a intenção dos requisitos Versão 2.0 Outubro de 2010

2 Alterações no documento Data Version Description 1 de outubro de de outubro de Alinhar o conteúdo com o novo PCI DSS v1.2 e implementar pequenas alterações observadas desde o original v Alinhar o conteúdo com o novo PCI DSS v2.0. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 2

3 Índice Alterações no documento...2 Prefácio...4 Virtualização... 5 Elementos dos dados do titular do cartão e de autenticação confidenciais...6 Localização dos dados do titular do cartão e dos dados de autenticação confidenciais... 8 Dados do rastro 1 vs. rastro relacionada para o Padrão de segurança de dados do PCI...10 para os Requisitos 1 e 2: Construa e mantenha uma rede segura...11 Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança para os Requisitos 3 e 4: Proteger os dados do titular do cartão...20 Requisito 3: Proteger os dados armazenados do titular do cartão Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades...30 Requisito 5: Usar e atualizar regularmente o software ou programas antivírus Requisito 6: Desenvolver e manter sistemas e aplicativos seguros para os Requisitos 7, 8 e 9: Implementar medidas de controle de acesso rigorosas...40 Requisito 7: Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de conhecimento para o negócio Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador Requisito 9: Restringir o acesso físico aos dados do titular do cartão para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente...51 Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão Requisito 11: Testar regularmente os sistemas e processos de segurança para o Requisito 12: Manter uma Política de Segurança de Informações...61 Requisito 12: Manter uma política que aborde a segurança das informações para todas as equipes para o Requisito A.1: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada Anexo A: Padrão de segurança de dados do PCI: documentos relacionados...69 Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 3

4 Prefácio Este documento descreve os 12 requisitos do Padrão de segurança de dados do Setor de cartões de pagamento (PCI DSS), junto com uma orientação para explicar o propósito de cada um deles. A finalidade deste documento é auxiliar comerciantes, prestadores de serviço e instituições financeiras que desejem conhecer mais a respeito do padrão de segurança de dados do setor de cartões de débito, bem como o significado específico e as intenções por trás dos requisitos detalhados para proteger os componentes do sistema (servidores, rede, aplicativos, etc). compatíveis com os ambientes de dados do titular do cartão. OBSERVAÇÃO: Navegando pelo PCI DSS: Conhecer a intenção dos requerimentos servirá apenas como orientação. Ao preencher uma avaliação on-site do PCI DSS ou um questionário de auto-avaliação (SAQ - Self Assessment Questionnaire), os Requisitos do PCI DSS dos Padrões de Segurança de Dados e os Questionários de auto-avaliação do PCI DSS 2.0 serão os documentos de registro. Os requisitos de segurança do PCI DSS se aplicam a todos os componentes do sistema. No contexto do PCI DSS, os "componentes do sistema" são definidos como qualquer componente de rede, servidor ou aplicativo que esteja incluído ou vinculado ao ambiente de dados do titular do cartão. Os componentes do sistema incluem também qualquer componente de virtualização, como máquinas virtuais, roteadores e comutadores virtuais, ferramentas virtuais, aplicativos e desktops virtuais e hipervisores. O ambiente de dados do titular do cartão compreende pessoas, processos e tecnologia que lidam com os dados do titular do cartão ou dados de autenticação confidenciais. Os componentes de rede podem incluir, mas não de forma exclusiva, firewalls, chaves, roteadores, pontos de acesso wireless, mecanismos de rede e outros mecanismos de segurança. Os tipos de servidor incluem, mas não se limitam a: web, aplicativo, banco de dados, autenticação, , proxy, NTP (network time protocol) e DNS (domain name server). Os aplicativos incluem todos os aplicativos adquiridos e personalizados, incluindo os aplicativos internos e externos (Internet, por exemplo). A primeira etapa de uma avaliação do PCI DSS é determinar precisamente o escopo da revisão. Ao menos anualmente e antes da avaliação anual, a entidade deve confirmar a precisão de seu escopo do PCI DSS ao identificar todos os locais e fluxos de dados do titular do cartão e assegurar que estejam incluídos no escopo do PCI DSS. Para confirmar a precisão e a adequação do escopo do PCI DSS, execute o seguinte: A entidade avaliada identifica e documenta a existência de todos os dados do titular do cartão em seu ambiente, para verificar que nenhum dado de titular do cartão existe fora do ambiente de dados do titular do cartão definido no momento (CDE). Assim que todos os locais dos dados do titular do cartão forem identificados e documentados, a entidade usa os resultados para verificar se o escopo do PCI DSS é adequado (por exemplo, os resultados podem ser um diagrama ou um inventário de locais de dados do titular de cartão). A entidade considera que qualquer dado do titular do cartão esteja no escopo da avaliação do PCI DSS e parte do CDE, a não ser que tal dado seja excluído ou migrado/consolidado no CDE definido atualmente. A entidade retém a documentação que mostra como o escopo do PCI DSS foi confirmado e os resultados, para a revisão da assessoria e/ou para referência durante a próxima atividade anual de confirmação do escopo do PCI SCC. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 4

5 A segmentação da rede ou o isolamento (separação) do ambiente de dados do titular do cartão do restante da rede corporativa não é um requisito do PCI DSS. Entretanto, é altamente recomendável como um método que reduzirá o escopo do ambiente de dados do titular do cartão. Um Assessor de Segurança Qualificado (QSA) pode auxiliar na determinação do escopo dentro do ambiente dos dados do titular do cartão, junto com orientação sobre como estreitar o escopo de uma avaliação do PCI DSS ao implementar uma segmentação de rede adequada. Se houver dúvidas quanto à consonância de uma determinada implantação em relação ao padrão ou a um requerimento específico, o PCI SSC recomenda às empresas que consultem o QSA para validar a implantação da tecnologia e dos processos e atender ao padrão de segurança de dados do PCI. A experiência dos QSAs em trabalhar com ambientes de rede complexos é boa para proporcionar melhores práticas e orientação ao comerciante ou prestador de serviços na tentativa de conquistar conformidade. A lista dos assessores de segurança qualificados do PCI SSC poderá ser encontrada em: Virtualização Se uma virtualização for implantada, todos os componentes que estiverem no ambiente virtual deverão ser identificados e considerados dentro do escopo para a revisão, incluindo os hosts individuais virtuais ou dispositivos, máquinas visitantes, aplicativos, interfaces de gerenciamento, consoles de gerenciamento centrais, hipervisores, etc. Todas as comunicações e fluxos de dados trocados entre os hosts deverão ser identificados e documentados, bem como aqueles trocados entre o componente virtual e os componentes do sistema. A implantação de um ambiente virtualizado deverá atender às inteções de todos os requerimentos de forma que os sistemas virtualizados possam de fato ser considerados hardwares separados. Por exemplo: deverá haver uma segmentação clara das funções e segregação de redes com níveis de segurança diferentes. A segmentação deverá evitar o compartilhamento dos ambientes de produção e de teste e desenvolvimento. A configuração virtual deverá ser protegida de forma que as vulnerabilidades em uma função não interfiram na segurança de outras. E dispositivos como USB ou em série não possam ser acessados por todas as instâncias virtuais. Além disso, todos os protocolos de interface de gerenciamento virtuais deverão ser incluídos na documentação do sistema, e deverão ser definidas funções e permissões para gerenciamento das redes virtuais e dos componentes virtuais do sistema. As plataformas de virtualização deverão ter a capacidade de aplicar a separação de tarefas e de privilégios menores, de forma a separar o gerenciamento de rede virtual do gerenciamento de servidor virtual. Deve-se ter atenção especial ao implantar os controles de autenticação, de forma a garantir que a autenticação dos usuários seja realizada nos componentes de sistema virtual adequados e que haja distinção entre as máquinas virtuais (VMs - virtual machines) do visitante e o hipervisor. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 5

6 Elementos dos dados do titular do cartão e de autenticação confidenciais O PCI DSS se aplica onde quer que os dados da conta sejam armazenados, processados ou transmitidos. Os Dados da Conta consistem em Dados do titular do cartão mais Dados de autenticação confidenciais, como segue: Os Dados do titular do cartão incluem: O número da conta principal (PAN) O nome do titular do cartão Data de vencimento Código de serviço Os Dados de autenticação confidenciais incluem: Dados em tarja magnética ou equivalentes em chip CAV2/CVC2/CVV2/CID PINs/Bloqueios de PIN O número da conta principal é o fator decisivo na aplicabilidade dos requisitos do PCI DSS. Os requisitos do PCI DSS são aplicáveis se um número de conta principal (PAN) for armazenado, processado ou transmitido. Caso o PAN não seja armazenado, processado ou transmitido, não serão aplicados os requisitos do sistema. Se o nome, código de serviço e/ou data de validade de um titular do cartão são armazenados processados ou transmitidos com o PAN ou, de outro modo, estão presentes no ambiente de dados do titular do cartão, eles devem ser protegidos de acordo com os Requisitos 3.3 e 3.4 que se aplicam somente ao PAN. O PCI DSS representa um conjunto mínimo de objetivos de controle que podem ser aperfeiçoados por leis e normas locais, regionais e do setor. Além disso, os requisitos legais ou regulatórios podem exigir proteção específica de informações pessoalmente identificáveis ou outros elementos de dados (por exemplo, o nome do titular do cartão) ou definir práticas de divulgação de uma entidade ligadas a informações de clientes. Os exemplos incluem a legislação relacionada à proteção de dados de clientes, privacidade, roubo de identidade ou segurança de dados. O PCI DSS não substitui leis locais ou regionais, regulamentos do governo ou outros requisitos legais. A tabela a seguir ilustra os elementos comumente usados do titular do cartão e dados de autenticação confidenciais; se o armazenamento de cada elemento de dados é permitido ou proibido; e se cada elemento de dados deve ser protegido. Esta tabela não tem a intenção de ser completa, mas é apresentada para ilustrar o tipo diferente de requisito que aplica-se a cada elemento de dados; Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 6

7 Dados da conta Dados do titular do cartão Dados de autenticação confidenciais 1 Elemento de dados O número da conta principal (PAN) Armazenamento permitido Sim Converte dados de conta armazenados ilegíveis pelo Requisito 3.4 Sim O nome do titular do cartão Sim Não Código de serviço Sim Não Data de vencimento Sim Não Dados completos da tarja magnética 2 Não Não armazenável pelo Requisito 3.2 CAV2/CVC2/CVV2/CID PIN/Bloco de PIN Não Não Não armazenável pelo Requisito 3.2 Não armazenável pelo Requisito 3.2 Os Requisitos 3.3 e 3.4 do PCI DSS aplicam-se apenas ao PAN. Se o PAN for armazenado com outros elementos dos dados do titular do cartão, somente o PAN deverá ser convertido como ilegível de acordo com o Requisito 3.4 do PCI DSS. O PCI DSS se aplica somente se os PANs são armazenados, processados e/ ou transmitidos. 1 2 Dados de autenticação confidenciais não devem ser armazenados após a autorização (mesmo se forem criptografados). Dados completos de rastreamento da tarja magnética, dados equivalentes no chip, ou em outro lugar. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 7

8 Localização dos dados do titular do cartão e dos dados de autenticação confidenciais Os dados confidenciais de autenticação consistem em dados de tarja magnética (ou trilha) 3, código de validação do cartão ou valor 4, e dados de PIN 5. O armazenamento de dados de autenticação confidenciais é proibido! Esses dados são muito valiosos para indivíduos malintencionados, pois permitem gerar cartões de pagamento falsos e criar transações fraudulentas. Consulte o Glossário de termos, abreviações e acrônimos utilizados no PCI DSS e no PA-DSS para obter a definição completa dos "dados confidenciais de autenticação". As imagens da frente e do verso do cartão exibidas a seguir mostram o local dos dados do titular do cartão e dos dados confidenciais de autenticação. Observação: O chip contém dados de trilha equivalentes, bem como outros dados confidenciais, incluindo o valor de verificação de chip de circuito integrado (IC - integrated circuit), também chamado de CVC, icvv, CAV3 ou icsc do chip. 3 Dados codificados na tarja magnética utilizados para autorização durante a transação com o cartão. Estes dados também poderão ser encontrados em um chip ou em outra parte do cartão. As entidades não podem reter esses dados após a autorização da transação. Os únicos elementos dos dados da tarja que podem ser retidos são o número da conta principal, o nome do titular do cartão, a data de vencimento e o código de serviço. 4 O valor de três ou quatro dígitos impresso à direita do painel de assinatura ou na frente do cartão de pagamento usado para verificar transações com cartão não presente. 5 Número de Identificação Pessoal inserido pelo titular do cartão durante uma transação com o cartão e/ou bloqueio de PIN criptografado dentro da mensagem da transação. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 8

9 Dados do rastro 1 vs. rastro 2 Se os dados completos de uma tarja (seja Rastro 1 ou Rastro 2, da tarja magnética, imagem da tarja magnética no chip ou outro local) forem armazenados, indivíduos mal-intencionados que obterem esses dados poderão reproduzir e vender cartões de pagamento no mundo inteiro. O armazenamento de dados completos da tarja também viola as regras operacionais das bandeiras, podendo ocasionar multas e penalidades. A ilustração abaixo fornece informações sobre os dados das Tarjas 1 e 2, descrevendo as diferenças e mostrando o layout dos dados conforme eles são armazenados na tarja magnética. Rastro 1 Rastro 2 Contém todos os campos do rastro 1 e do rastro 2 Comprimento de até 79 caracteres Tempo de processamento menor para transmissões discadas mais antigas Comprimento de até 40 caracteres Observação: Os campos de dados opcionais são definidos pelo emissor do cartão pela marca do cartão de débito. Os campos definidos pelo emissor que contêm dados que o emissor ou a bandeira do cartão de débito não consideram como dados confidenciais de autenticação poderão ser incluídos na porção de dados opcionais da tarja, e terão permissão para armazenar estes dados específicos em situações e condições específicas da forma definida pelo emissor ou pela bandeira do cartão de débito. Entretanto, todos os dados considerados confidenciais de autenticação, contidos ou não em um campo de dados opcionais, não deverão ser armazenados após a autorização. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 9

10 relacionada para o Padrão de segurança de dados do PCI Construa e mantenha uma rede segura Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança Proteger os dados do titular do cartão Requisito 3: Proteger os dados armazenados do titular do cartão Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas Manter um programa de gerenciamento de vulnerabilidades Requisito 5: Usar e atualizar regularmente o software ou programas antivírus Requisito 6: Desenvolver e manter sistemas e aplicativos seguros Implementar medidas de controle de acesso rigorosas Requisito 7: Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de divulgação dos negócios Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador Requisito 9: Restringir o acesso físico aos dados do titular do cartão Monitorar e Testar as Redes Regularmente Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão Requisito 11: Testar regularmente os sistemas e processos de segurança Manter uma Política de Segurança de Informações Requisito 12: Manter uma política que aborde a segurança das informações para todas as equipes. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 10

11 para os Requisitos 1 e 2: Construa e mantenha uma rede segura Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão Firewalls são dispositivos do computador que controlam o tráfego do computador permitido entre a rede de uma empresa (interna) e redes não confiáveis (externa), assim como o tráfego dentro e fora de muitas áreas confidenciais na rede confiável interna de uma empresa. O ambiente de dados do titular do cartão é um exemplo de uma área mais sensível dentro da rede confiável de uma empresa. Um firewall examina todo o tráfego da rede e bloqueia aquelas transmissões que não atendem aos critérios de segurança específicos. Todos os sistemas devem ser protegidos do acesso não autorizado de redes não confiáveis, seja acessando o sistema por meio da Internet como e-commerce, acesso à Internet através dos navegadores na área de trabalho por parte dos funcionários, acesso via dos funcionários, conexão dedicada como conexões entre negócios, por meio de redes sem fio ou de outras fontes. Com freqüência, trajetos aparentemente insignificantes que direcionam ou partem de redes não confiáveis podem fornecer caminhos não protegidos aos sistemas principais. Os firewalls são um mecanismo de proteção essencial para qualquer rede de computador. Outros componentes do sistema podem oferecer a funcionalidade de filirena, contanto que atendam aos requisitos mínimos para firewalls, conforme o Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do titular do cartão para oferecer a funcionalidade do firewall, esses dispositivos deverão ser incluídos no escopo e na avaliação do Requisito 1. Requisito 1.1 Definir os padrões de configuração do firewall e do roteador que incluam o seguinte: Firewalls e roteadores são os principais componentes da arquitetura que controlam a entrada e a saída da rede. Esses dispositivos são software ou hardware que bloqueiam acesso indesejado e gerenciam acesso autorizado de e para a rede. Sem políticas e procedimentos para documentar como a equipe deve configurar firewalls e roteadores, fica fácil uma empresa perder sua primeira linha de defesa na proteção de dados. As políticas e os procedimentos ajudarão a garantir que a primeira linha de defesa da organização na proteção de seus dados continue forte. Os ambientes virtuais onde os fluxos de dados não transitarem por uma rede física deverão ser avaliados de forma a garantir que se obtenha a segmentação da rede Um processo formal para aprovar e testar todas as conexões de rede e alterações às configurações do firewall e do roteador Uma política e um processo para aprovar e testar todas as conexões e alterações nos firewalls e roteadores ajudará a evitar problemas de segurança causados pela má configuração da rede, do roteador ou do firewall. Os fluxos de dados entre máquinas virtuais deverão ser incluídos nas políticas e processos. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 11

12 1.1.2 Diagrama da rede atual com todas as conexões com relação aos dados do titular do cartão, incluindo quaisquer redes sem fio Os diagramas de rede permitem que a organização identifique o local de todos os dispositivos de rede. Além disso, o diagrama de rede pode ser usado para mapear o fluxo de dados dos dados do titular do cartão por toda a rede e entre cada dispositivo, a fim de entender totalmente o escopo do ambiente dos dados do titular do cartão. Sem os diagramas da rede atual e do fluxo de dados, os dispositivos com dados do titular do cartão podem ser ignorados e sem querer deixados de fora dos controles de segurança em camadas implementados para PCI DSS e, assim, vulneráveis ao comprometimento. Os diagramas de rede e fluxo de dados deverão incluir componentes do sistema virtual e fluxos de dados trocados entre os hosts Requisitos para um firewall em cada conexão da Internet e entre qualquer zona desmilitarizada (DMZ) e a zona da rede interna 1.1.4Descrição de grupos, funções e responsabilidades quanto ao gerenciamento lógico dos componentes da rede Documentação e justificativa comercial para o uso de todos os serviços, protocolos e portas permitidas, incluindo a documentação dos recursos de segurança implementados para os protocolos considerados inseguros. Exemplos de serviços, protocolos ou portas inseguros incluem mas não são limitados a FTP, Telnet, POP3, IMAP e SNMP. Usar um firewall e todas as conexões que entram e saem da rede permite que a organização monitore e controle a entrada e saída de acesso, e minimize as chances de um indivíduo mal-intencionado de obter acesso à rede interna. Essa descrição de funções e a atribuição da responsabilidade garante que alguém seja claramente responsável pela segurança de todos os componentes e esteja ciente da responsabilidade, e também que nenhum dispositivo fique sem gerenciamento. Muitas vezes ocorrem comprometimentos decorrentes de serviços e portas não utilizados ou inseguros, visto que é freqüente eles possuírem vulnerabilidades conhecidas e muitas organizações estão vulneráveis a esses tipos de comprometimentos, pois não aplicam patches nas vulnerabilidades de segurança para serviços, protocolos e portas que não utilizam (ainda que as vulnerabilidades ainda estejam presentes). Cada organização deve decidir claramente quais serviços, protocolos e portas são necessários para seus negócios, documentá-los nos registros e garantir que todos os outros serviços, protocolos e portas sejam desabilitados ou removidos. Além disso, as organizações devem pensar em bloquear todo o tráfego e somente reabrir essas portas depois de ser determinada e documentada uma necessidade. Além disso, existem muitos serviços, protocolos ou portas de que uma empresa pode precisar (ou estarem ativados por padrão) que normalmente sejam usados por indivíduos mal-intencionados para comprometer uma rede. Se esses serviços, protocolos e portas inseguros forem necessários para a empresa, o risco apresentado pelo uso desses protocolos deve ser claramente entendido e aceito pela organização, o uso do protocolo deve ser justificado e os recursos de segurança que permitem que esses protocolos sejam usados com segurança deverão ser documentados e implementados. Se esses serviços, protocolos ou portas inseguros não forem necessários para a empresa, eles deverão ser desativados ou removidos. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 12

13 1.1.6 Requisito para analisar os conjuntos de regras do firewall e do roteador pelo menos a cada seis meses 1.2 Elaborar uma configuração de firewall e do roteador que restrinja as conexões entre redes não confiáveis e quaisquer componentes do sistema no ambiente de dados do titular do cartão. Observação: Uma rede não confiável é qualquer rede que seja externa às redes que pertencem à entidade em análise e/ou que esteja além da capacidade da entidade de controlar ou gerenciar Restringir o tráfego de entrada e saída para aquele que é necessário para o ambiente de dados do titular do cartão Proteger e sincronizar os arquivos de configuração do roteador. Essa análise dá à organização a oportunidade de, pelo menos a cada seis meses, limpar todas as regras desnecessárias, obsoletas ou incorretas, e garantir que todos os conjuntos de regras só permitam que serviços e portas não autorizados correspondam às justificativas de negócios. É aconselhável fazer essas análises com mais freqüência, como mensalmente, para garantir que os conjuntos de regras estejam atualizados e correspondam às necessidades da empresa, sem abrir furos na segurança e correr riscos desnecessários. É essencial instalar a proteção de rede, principalmente um componente do sistema com (pelo menos) a função de firewall de inspeção com status, entre a rede interna confiável e outra rede não confiável externa ou que esteja fora do poder de controle e administração da empresa. A não-implementação dessa medida corretamente significa que a entidade estará vulnerável ao acesso não autorizado de indivíduos ou softwares mal-intencionados. Se o firewall estiver instalado, mas não tiver regras que controlam ou limitam determinado tráfego, indivíduos mal-intencionados ainda poderão explorar os protocolos e portas vulneráveis para atacar sua rede. Esse requisito destina-se a evitar que indivíduos mal-intencionados acessem a rede da empresa por meio de endereços IP não autorizados ou usem serviços, protocolos ou portas de forma não autorizada (por exemplo, enviando dados obtidos dentro da sua rede para um servidor não confiável). Todos os firewalls devem incluir uma regra que negue todo tráfego de entrada e saída não especificamente necessário. Isso evita o surgimento de buracos inadvertidos que permitam a entrada ou saída de outros tráfegos indesejados e potencialmente prejudiciais. Apesar de os arquivos de configuração de execução normalmente serem implementados com configurações seguras, os arquivos de inicialização (os roteadores só executam esses arquivos na reinicialização) podem não ser implementados com as mesmas configurações seguras, pois eles só são executados ocasionalmente. Quando o roteador for reinicializado sem as mesmas configurações seguras que as dos arquivos de configuração de execução, o resultado pode ser regras mais fracas que permitam que indivíduos malintencionados entrem na rede, pois os arquivos de inicialização podem não ter sido implementados com as mesmas configurações de segurança que os arquivos de configuração de execução. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 13

14 1.2.3 Instalar firewalls de perímetro entre quaisquer redes sem fio e o ambiente de dados do titular do cartão, e configurar esses firewalls para recusar ou controlar (se esse tráfego for necessário para fins comerciais) qualquer tráfego a partir do ambiente sem fio no ambiente de dados do titular do cartão. 1.3 Proibir o acesso público direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do cartão Implemente uma DMZ para limitar o tráfego somente para componentes do sistema que oferece serviços, protocolos e portas acessíveis publicamente Limitar o tráfego de entrada da Internet a endereços IP na DMZ Não permitir a entrada ou saída de nenhuma rota direta com relação ao tráfego entre a Internet e o ambiente de dados do titular do cartão. A implementação conhecida (ou desconhecida) e a exploração da tecnologia wireless dentro de uma rede é um caminho comum para indivíduos malintencionados ganharem acesso à rede e aos dados do titular do cartão. Se um dispositivo wireless ou uma rede forem instalados sem o conhecimento da empresa, um indivíduo mal-intencionado pode fácil e invisivelmente entrar na rede. Se os firewalls não restringirem o acesso das redes wireless no ambiente do cartão de pagamento, indivíduos mal-intencionados que tiverem acesso não autorizado à rede wireless poderão se conectar facilmente ao ambiente do cartão de pagamento e comprometer as informações da conta. Deverão ser instalados firewalls entre as redes sem fio e o CDE, independente da finalidade do ambiente a que a rede sem fio estiver conectada. Isto deverá incluir, ao menos, redes corporativas, revendedores, ambientes de armazenamento, etc. O objetivo do firewall é gerenciar e controlar todas as conexões entre os sistemas públicos e os internos (especialmente aqueles que armazenam os dados do titular do cartão). Se for permitido o acesso direto entre sistemas públicos e aqueles que armazenam os dados do titular do cartão, as proteções oferecidas pelo firewall serão ignoradas e os componentes do sistema que armazenam os dados do titular do cartão poderão ser comprometidos. O DMZ é a parte da rede responsável pelo gerenciamento das conexões entre a Internet (ou redes não confiáveis) e os serviços internos de que a empresa precisa disponibilizar para o público (como servidor web). Essa é a primeira linha de defesa ao isolar e separar o tráfego que precisa se comunicar com a rede interna daquele que não precisa. Este recurso será utilizado para evitar que indivíduos mal-intencionados acessem a rede da empresa através de endereços de IP não autorizados ou por meio de serviços, protocolos ou portas de forma não autorizada. A interrupção das conexões de IP oferecem uma oportunidade para inspeção e restrição de fontes/destinos, ou inspeção/bloqueio do contúdo, evitando assim o acesso não filtrado entre pessoas não confiáveis e ambientes confiáveis. A interrupção das conexões de IP oferecem uma oportunidade para inspeção e restrição de fontes/destinos, ou inspeção/bloqueio do contúdo, evitando assim o acesso não filtrado entre pessoas não confiáveis e ambientes confiáveis. Isto ajudará a evitar, por exemplo, que indivídos mal-intencionados enviem dados obtidos na rede para um servidor externo não confiável em uma rede não confiável Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 14

15 1.3.4 Não permitir que endereços internos sejam transmitidos via Internet na DMZ Não permitir o tráfego de saída não autorizado do ambiente de dados do titular do cartão para a Internet Implementar inspeção com status, também conhecida como filtragem de pacote dinâmico. (Ou seja, somente conexões "estabelecidas" são permitidas na rede.) Implementar os componentes do sistema que armazenam dados do titular do cartão (como banco de dados) em uma zona da rede interna, separada da DMZ e de outras redes não confiáveis. Normalmente um pacote contém os endereços de IP do computador que originalmente o enviou, permitindo que os outros computadores da rede saibam de onde ele vem. Em certos casos, esse endereço de IP de envio sofrerá spoofing por indivíduos mal-intencionados. Por exemplo: indivíduos mal-intencionados enviam um pacote com um endereço spoof, para que (a menos que seu firewall proíba) o pacote consiga entrar na sua rede pela Internet, parecendo que se trata de um tráfego interno e, portanto, legítimo. Quando o indivíduo mal-intencionado estiver dentro da sua rede, ele poderá começar a comprometer seus sistemas. A filtragem ingressa é uma técnica que você pode usar no seu firewall para filtrar pacotes que entram na sua rede, como, entre outras coisas, garantindo que os pacotes não sofram spoofing, parecendo que vêm de sua própria rede interna. Para obter mais informações sobre a filtragem de pacotes, pense em obter informações sobre uma técnica complementar chamada filtragem egressa. Todo tráfego que sair do ambiente de dados do titular do cartão deverá ser avaliado para garantir que o tráfego de saída esteja de acordo com as regras autorizadas preestabelecidas. As conexões deverão ser inspecionadas para retringir o tráfego de forma a permitir apenas as comunicações autorizadas (por exemplo restringindo portas/endereços de origem/destino ou bloqueando o conteúdo). Onde não forem permitidas conexões de entrada, as conexões de saída poderão ser alcançadas através de arquiteturas ou componentes de sistema que interrompam e inspecionem a conexão de IP. Um firewall que executa inspeção de pacotes com status mantém o status (ou estado) de cada conexão para o firewall. Ao manter o "status, o firewall sabe se o que parece ser uma resposta a uma conexão anterior é de fato uma resposta (visto que isso lembra a conexão anterior) ou se trata-se de um indivíduo ou software mal-intencionado tentando fazer spoofing ou enganar o firewall para permitir a conexão. Os dados do titular do cartão exigem o mais alto nível de proteção de informações. Se os dados do titular do cartão estiverem localizados dentro da DMZ, o acesso a essas informações será mais fácil para um atacante externo, pois há poucas camadas a serem penetradas. Observação: a intenção deste requisito não inclui armazenamento em memória volátil. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 15

16 1.3.8 Não divulgar endereços de IP privados e informações de roteamento a partes não autorizadas. Observação: Métodos para camuflar o endereço de IP podem incluir, mas não se limitam a: Network Address Translation (NAT) Implementação de servidores contendo dados do titular do cartão atrás dos servidores de proxy/firewalls ou caches de conteúdo, Remoção ou filtragem das propagandas de rota para redes privadas que empregam endereçamento registrado. Uso interno do espaço de endereço RFC1918 em vez de endereço registrado. É importante restringir a transmissão de endereços IP de forma a evitar que os hackers "descubram" os endereços IP da rede interna e utilizem essas informações para acessar a rede. Os meios eficazes de atender à inteção deste requisito podem variar de acordo com a tecnologia de rede específica utilizada em seu ambiente. Por exemplo: os controles utilizados para atender a estes requisitos em redes IPv4 poderão ser diferentes daqueles utilizados em redes IPv6. Uma técnica para evitar que as informações de endereço IP sejam descobertas em uma rede IPv4 é implantar a tradução do endereço de rede (NAT - Network Address Translation). A NAT, que normalmente é gerada firewall, permite que a organização tenha endereços internos que só sejam visíveis dentro da rede, e um endereço externo que seja visível externamente. Se o firewall não ocultar (ou mascarar) os endereços de IP da rede interna, um indivíduo mal-intencionado pode descobrir os endereços de IP internos e tentar acessar a rede com um endereço de IP obtido por spoofing. Em redes IPv4 o espaço de endereços RFC1918 é reservado para endereçamentos internos e não poderá ser roteado pela Internet. Dessa forma, é o preferido para endereçamento de IP de redes internas. Entretanto, as empresas poderão ter suas razões para utilizar em suas redes internas outros espaços de endereços que não sejam o RFC1918. Neste caso, deverá ser utilizada uma forma de prevenção de propagandas de rota para evitar que o espaço de endereços interno seja transmitido pela Internet ou divulgado a pessoas não autorizadas. 1.4Instalar o software de firewall pessoal em quaisquer computadores móveis e/ou de propriedade do funcionário com conectividade direta à Internet (por exemplo, laptops usados pelos funcionários), que são usados para acessar a rede da empresa. Se o computador não tiver instalado em si um firewall ou programa antivírus, spyware, Trojans, vírus, worms e rootkits (malware) poderão ser baixados e/ou instalados sem conhecimento. O computador fica ainda mais vulnerável quando estiver diretamente conectado à Internet, e não estiver por trás do firewall corporativo, caso em que o malware carregado em um computador poderá buscar com más intenções nas informações dentro da rede quando o computador for reconectado à rede corporativa. Observação: A intenção deste requisito se aplica a computadores de acesso remoto, sejam eles de propriedade do funcionário ou da empresa. Os sistemas que não podem ser gerenciados pelas políticas empresariais introduzem fraquezas ao perímetro e oferecem oportunidades a pessoas mal-intencionadas. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 16

17 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança Indivíduos mal-intencionados (dentro e fora de uma empresa) com frequência usam senhas padrão do fornecedor e outras configurações padrão do fornecedor para comprometer os sistemas. Essas senhas e configurações são bastante conhecidas pelas comunidades de hackers e facilmente determinadas por meio de informações públicas. Requisito 2.1 Sempre alterar os padrões disponibilizados pelo fornecedor antes de instalar um sistema na rede por exemplo, incluir senhas, strings de comunidade de SNMP (simple network management protocol) e a eliminação de contas desnecessárias Em ambientes sem fio conectados ao ambiente de dados do titular do cartão ou que transmitam dados do titular do cartão, alterar os padrões do fornecedor sem fio, incluindo, mas não se limitando a, chaves de criptografia sem fio padrão, senhas e strings de comunidades de SNMP. 2.2 Desenvolver padrões de configuração para todos os componentes do sistema. Certificar-se de que esses padrões abrangem todas as vulnerabilidades de segurança conhecidas e estão em conformidade com os padrões de fortalecimento do sistema aceitos pelo setor. As fontes dos padrões de proteção do sistema aceitos pelo setor podem incluir, mas não se limitam a: Center for Internet Security (CIS) International Organization for Standardization (ISO) SysAdmin Audit Network Security (SANS) National Institute of Standards and Technology (NIST) Indivíduos mal-intencionados (dentro e fora de uma empresa) com freqüência usam senhas padrão do fornecedor e outras configurações padrão do fornecedor para comprometer os sistemas. Essas configurações são conhecidas nas comunidades de hackers e deixam seu sistema altamente vulnerável a ataques. Muitos usuários instalam esses dispositivos sem aprovação da gerência e não alteram as configurações-padrão nem fazem as configurações de segurança. Se as redes wireless não forem implementadas com configurações de segurança suficientes (incluindo a alteração das configurações-padrão), os sniffers da rede wireless conseguem espreitar o tráfego, capturar dados e senhas e entrar e atacar sua rede com facilidade. Além disso, o protocolo de troca de chaves para a versão antiga da criptografia o x (WEP) foi quebrado e pode tornar a criptografia inútil. Verifique se o firmware dos dispositivos está atualizado para suportar protocolos mais seguros (por exemplo, WPA2). Existem pontos fracos conhecidos em vários sistemas operacionais, bancos de dados e aplicativos empresariais, e existem também formas conhecidas de configurar esses sistemas para corrigir as vulnerabilidades de segurança. Para ajudar quem não é especialista nisso, as organizações de segurança criaram recomendações para proteção do sistema que aconselham como corrigir esses pontos fracos. Se os sistemas forem deixados com esses pontos fracos, como por exemplo configurações de arquivo fracas ou serviços e protocolos com falhas (para aqueles serviços e protocolos que não são necessários com freqüência), um transgressor poderá usar várias e conhecidas explorações para atacar serviços e protocolos vulneráveis e, assim, ganhar acesso à rede da organização. Websites de origem onde você poderá aprender sobre as melhores práticas da indústria que poderão ajudá-lo a implantar padrões de configuração incluindo, mas não apenas: Os padrões de configuração do sistema também deverão ser mantidos atualizados para garantir que as deficiências recentemente identificadas sejam corrigidas antes de o sistema ser instalado na rede. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 17

18 2.2.1Implementar somente uma função principal por servidor para evitar funções que exigem diferentes níveis de segurança coexistindo no mesmo servidor. (Por exemplo, servidores da Web, servidores do banco de dados e DNS devem ser implementados em servidores separados.) Observação: Onde tecnologias de virtualização estiverem em uso, implemente somente uma função principal por componente do sistema virtual. Isso serve para garantir que os padrões de configuração do sistema da sua organização e os processos relacionados abordem funções do servidor que precisem ter níveis de segurança diferentes ou que possam introduzir pontos fracos de segurança em outras funções do mesmo servidor. Por exemplo: 1. Um banco de dados que precise ter medidas de segurança robustas estaria arriscado a compartilhar um servidor com um aplicativo da Web, que precisa ser aberto e interagir diretamente com a Internet. 2. A não-aplicação de um patch em uma função aparentemente pequena pode resultar em comprometimento que cause impacto em outras funções mais importantes (como um banco de dados) no mesmo servidor. Este requisito poderá ser utilizado em todos os servidores do ambiente de dados do titular do cartão (geralmente com base em Unix, Linux ou Windows). Este requisito não deverá ser aplicado em sistemas que originalmente implantem níveis de segurança em um único servidor (ex.: mainframe). Onde forem utilizadas tecnologias de virtualização, cada componente virtual (ex.: máquina virtual, comutador virtual, aplicativo de segurança virtual, etc) deverá ser considerado delimitador "de sistema". Os hipervisores individuais poderão ser compatíveis com diversas funções, mas uma única máquina virtual deveria aderir à regra "uma função primária". Nestas circunstâncias, o comprometimento do hipervisor poderá levar ao comprometimento de todas as funções do sistema. Consequentemente, o nível de risco também deverá ser considerado ao localizar diversas funções ou componentes em um único sistema físico Ativar somente serviços, protocolos, daemons, etc. necessários e seguros, conforme exigido para a função do sistema. Implantar recursos de segurança para todos os serviços, protocolos ou daemons exigidos que forem considerados não seguros. Por exemplo: utilizar tecnologias como SSH, S-FTP, SSL ou IPSec VPN para proteger sistemas como NetBIOS, compartilhamento de arquivos, Telnet, FTP, etc Configurar os parâmetros de segurança do sistema para impedir o uso incorreto. Conforme informado no item 1.1.5, existem muitos protocolos de que uma empresa pode precisar (ou estarem ativados por padrão) que normalmente sejam usados por indivíduos mal-intencionados para comprometer uma rede. Para garantir que apenas os serviços e protocolos necessários sejam ativados e que todos os serviços e protocolos não seguros sejam protegidos adequadamente antes da implantação de novos servidores, este requisito deverá fazer parte dos padrões de configuração da empresa e dos processos relacionados. Isso serve para garantir que os padrões de configuração do sistema de sua organização e os processos relacionados abordem especificamente as configurações e os parâmetros de segurança que tenham implicações de segurança conhecidas. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 18

19 2.2.4 Remover todas as funcionalidades desnecessárias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores da Web desnecessários. 2.3 Criptografar todo o acesso administrativo não console durante a criptografia robusta. Usar tecnologias como SSH, VPN ou SSL/TLS para o gerenciamento baseado na Web e outros acessos administrativos não-console. 2..4Os provedores de hospedagem compartilhada devem proteger cada ambiente hospedado da entidade e os dados do titular do cartão. Esses provedores devem atender a requisitos específicos, conforme detalhado no Apêndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada. Os padrões de proteção do servidor devem incluir processos para resolver funcionalidades desnecessárias com implicações de segurança específicas (como remover/desativar FTP ou o servidor da Web, caso o servidor não execute essas funções). Se a administração remota não for feita com autenticação segura e comunicações criptografadas, informações confidenciais de nível administrativo ou operacional (como as senhas do administrador) poderão ser reveladas a um espião. Um indivíduo mal-intencionado pode usar essas informações para acessar a rede, tornar-se administrador e roubar os dados. Isso serve para provedores de hospedagem que oferecem ambientes de hospedagem compartilhada para vários clientes no mesmo servidor. Quando todos os dados estiverem no mesmo servidor e sob controle de um único ambiente, muitas vezes essas configurações nesses servidores compartilhados não serão gerenciáveis por clientes individuais, permitindo que os clientes adicionem funções e scripts inseguros que causam impacto na segurança de todos os outros ambientes de clientes e, assim, facilitando para um indivíduo malintencionado comprometer os dados de um cliente, obtendo acesso a todos os dados dos outros clientes. Veja o Anexo A. Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 19

20 para os Requisitos 3 e 4: Proteger os dados do titular do cartão Requisito 3: Proteger os dados armazenados do titular do cartão Métodos de proteção como criptografia, truncamento, mascaramento e referenciamento são componentes essenciais da proteção de dados do titular do cartão. Se um invasor burlar outros controles de segurança e obtiver acesso aos dados criptografados, sem as chaves criptográficas adequadas, os dados estarão ilegíveis e inutilizáveis para aquele indivíduo. Outros métodos eficientes de proteção dos dados armazenados devem ser considerados como oportunidades potenciais de minimização dos riscos. Por exemplo, os métodos para minimizar os riscos incluem não armazenar os dados do titular do cartão a menos que seja absolutamente necessário, truncar os dados do titular do cartão se um PAN completo não for necessário e não enviar o PAN em s não criptografados. Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS para obter definições de "criptografia robusta" e outros termos do PCI DSS. Requisito 3.1Manter a armazenagem dos dados do titular do cartão o mínimo possível, implementar políticas, processos e procedimentos de retenção e descarte de dados Implementar uma política de retenção e descarte de dados que inclua: Limite da quantia de dados armazenados e do tempo de retenção ao que é exigido pelos requisitos legais, regulatórios e comerciais Processos para exclusão segura de dados quando não mais necessários Requisitos de retenção específicos para dados de titular do cartão Processos trimestrais manuais ou automáticos para identificar e excluir com segurança os dados do titular do cartão que excederem os requisitos de retenção definidos Políticas formais de retenção de dados identificam quais dados precisam ser retidos e onde ficam, de forma a serem excluídos ou destruídos com segurança assim que não forem mais necessários. Para definir os requisitos de retenção adequados, a empresa deverá primeiro conhecer suas necessidades de negócios, bem como as responsabilidades legais e regulamentares que se aplicam à indústria ou ao tipo dos dados que serão retidos. O armazenamento prolongado dos dados do titular do cartão além das necessidades da empresa cria um risco desnecessário. Os únicos dados do titular do cartão que podem ser armazenados são o número da conta principal, ou PAN (desde que ilegível), data de vencimento, nome e código de serviço. Implementar métodos de exclusão seguros garante que os dados não poderão ser recuperados quando não forem mais necessários. Lembre-se: se você não precisar, não os armazene! Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 20