Navegando pelo PCI DSS

Transcrição

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
Alterações no documento
Data
Version
Description
1 de outubro de
2008
1.2
Alinhar o conteúdo com o novo PCI DSS v1.2 e implementar pequenas alterações observadas
desde o original v1.1.
28 de outubro de
2010
2.0
Alinhar o conteúdo com o novo PCI DSS v2.0.
Navegando pelo PCI DSS: Conhecer a inteção dos requisitos, v2.0
Copyright 2010 Conselho de Padrões de Segurança LLC do PCI
Outubro de 2010
Página 2
Í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 2 ................................................................................................................................................................................. 9
Orientação relacionada para o Padrão de segurança de dados do PCI.......................................................................10
Orientação 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 ........................................................... 11
Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança ......................... 17
Orientação para os Requisitos 3 e 4: Proteger os dados do titular do cartão.............................................................20
Requisito 3: Proteger os dados armazenados do titular do cartão ....................................................................................................................... 20
Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas................................................................. 28
Orientação para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades ........................30
Requisito 5: Usar e atualizar regularmente o software ou programas antivírus ................................................................................................... 30
Requisito 6: Desenvolver e manter sistemas e aplicativos seguros ..................................................................................................................... 32
Orientação para os Requisitos 7, 8 e 9: Implementar medidas de controle de acesso rigorosas .............................40
Requisito 7: Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de conhecimento para o negócio .................... 40
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador ................................................................. 42
Requisito 9: Restringir o acesso físico aos dados do titular do cartão.................................................................................................................. 47
Orientação para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente.................................................51
Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão ........................ 51
Requisito 11: Testar regularmente os sistemas e processos de segurança ........................................................................................................ 55
Orientação para o Requisito 12: Manter uma Política de Segurança de Informações................................................61
Requisito 12: Manter uma política que aborde a segurança das informações para todas as equipes. ............................................................... 61
Orientação para o Requisito A.1: Requisitos adicionais do PCI DSS para provedores de hospedagem
compartilhada................................................... .................................................................................................................67
Anexo A:
Padrão de segurança de dados do PCI: documentos relacionados........................................................69
Outubro de 2010
Página 3
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, e-mail, proxy, NTP (network time
protocol) e DNS (domain name server).
Os aplicativos incluem todos os aplicativos adquiridos e personalizados, incluindo os aplicativos internos e externos (Internet, por
exemplo).
A primeira etapa de uma avaliação do PCI DSS é determinar precisamente o escopo da revisão. Ao menos anualmente e antes da avaliação
anual, a entidade deve confirmar a precisão de seu escopo do PCI DSS ao identificar todos os locais e fluxos de dados do titular do cartão e
assegurar que estejam incluídos no escopo do PCI DSS. Para confirmar a precisão e a adequação do escopo do PCI DSS, execute o seguinte:
A entidade avaliada identifica e documenta a existência de todos os dados do titular do cartão em seu ambiente, para verificar que
nenhum dado de titular do cartão existe fora do ambiente de dados do titular do cartão definido no momento (CDE).
Assim que todos os locais dos dados do titular do cartão forem identificados e documentados, a entidade usa os resultados para verificar
se o escopo do PCI DSS é adequado (por exemplo, os resultados podem ser um diagrama ou um inventário de locais de dados do titular
de cartão).
A entidade considera que qualquer dado do titular do cartão esteja no escopo da avaliação do PCI DSS e parte do CDE, a não ser que tal
dado seja excluído ou migrado/consolidado no CDE definido atualmente.
A entidade retém a documentação que mostra como o escopo do PCI DSS foi confirmado e os resultados, para a revisão da assessoria
e/ou para referência durante a próxima atividade anual de confirmação do escopo do PCI SCC.
Outubro de 2010
Página 4
A segmentação da rede ou o isolamento (separação) do ambiente de dados do titular do cartão do restante da rede corporativa não é um
requisito do PCI DSS. Entretanto, é altamente recomendável como um método que reduzirá o escopo do ambiente de dados do titular do cartão.
Um Assessor de Segurança Qualificado (QSA) pode auxiliar na determinação do escopo dentro do ambiente dos dados do titular do cartão, junto
com orientação sobre como estreitar o escopo de uma avaliação do PCI DSS ao implementar uma segmentação de rede adequada.
Se houver dúvidas quanto à consonância de uma determinada implantação em relação ao padrão ou a um requerimento específico, o PCI SSC
recomenda às empresas que consultem o QSA para validar a implantação da tecnologia e dos processos e atender ao padrão de segurança de
dados do PCI. A experiência dos QSAs em trabalhar com ambientes de rede complexos é boa para proporcionar melhores práticas e orientação
ao comerciante ou prestador de serviços na tentativa de conquistar conformidade. A lista dos assessores de segurança qualificados do PCI SSC
poderá ser encontrada em: https://www.pcisecuritystandards.org.
Virtualização
Se uma virtualização for implantada, todos os componentes que estiverem no ambiente virtual deverão ser identificados e considerados dentro do
escopo para a revisão, incluindo os hosts individuais virtuais ou dispositivos, máquinas visitantes, aplicativos, interfaces de gerenciamento,
consoles de gerenciamento centrais, hipervisores, etc. Todas as comunicações e fluxos de dados trocados entre os hosts deverão ser
identificados e documentados, bem como aqueles trocados entre o componente virtual e os componentes do sistema.
A implantação de um ambiente virtualizado deverá atender às inteções de todos os requerimentos de forma que os sistemas virtualizados
possam de fato ser considerados hardwares separados. Por exemplo: deverá haver uma segmentação clara das funções e segregação de redes
com níveis de segurança diferentes. A segmentação deverá evitar o compartilhamento dos ambientes de produção e de teste e desenvolvimento.
A configuração virtual deverá ser protegida de forma que as vulnerabilidades em uma função não interfiram na segurança de outras. E
dispositivos como USB ou em série não possam ser acessados por todas as instâncias virtuais.
Além disso, todos os protocolos de interface de gerenciamento virtuais deverão ser incluídos na documentação do sistema, e deverão ser
definidas funções e permissões para gerenciamento das redes virtuais e dos componentes virtuais do sistema. As plataformas de virtualização
deverão ter a capacidade de aplicar a separação de tarefas e de privilégios menores, de forma a separar o gerenciamento de rede virtual do
gerenciamento de servidor virtual.
Deve-se ter atenção especial ao implantar os controles de autenticação, de forma a garantir que a autenticação dos usuários seja realizada nos
componentes de sistema virtual adequados e que haja distinção entre as máquinas virtuais (VMs - virtual machines) do visitante e o hipervisor.
Outubro de 2010
Página 5
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;
Outubro de 2010
Página 6
Armazenamento
permitido
Converte dados de conta
armazenados ilegíveis pelo
Requisito 3.4
O número da conta principal
(PAN)
Sim
Sim
Sim
Não
Código de serviço
Sim
Não
Data de vencimento
Sim
Não
Dados completos da tarja
2
magnética
Não
Não armazenável pelo
Requisito 3.2
CAV2/CVC2/CVV2/CID
Não
Requisito 3.2
PIN/Bloco de PIN
Não
Requisito 3.2
Dados da conta
Elemento de dados
Dados do
titular do
cartão
Dados de
autenticação
confidenciais
1
Os Requisitos 3.3 e 3.4 do PCI DSS aplicam-se apenas ao PAN. Se o PAN for armazenado com outros elementos dos dados do titular do 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.
Outubro de 2010
Página 7
Localização dos dados do titular do cartão e dos dados de autenticação confidenciais
3
4
Os dados confidenciais de autenticação consistem em dados de tarja magnética (ou trilha) , código de validação do cartão ou valor , e dados de
5
PIN . 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
4
5
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.
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.
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.
Outubro de 2010
Página 8
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
Contém todos os campos do rastro 1 e do rastro 2
Comprimento de até 79 caracteres
Rastro 2
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.
Outubro de 2010
Página 9
Orientação 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.
Outubro de 2010
Página 10
Orientação 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 e-mail dos
funcionários, conexão dedicada como conexões entre negócios, por meio de redes sem fio ou de outras fontes. Com freqüência, trajetos
aparentemente insignificantes que direcionam ou partem de redes não confiáveis podem fornecer caminhos não protegidos aos sistemas
principais. Os firewalls são um mecanismo de proteção essencial para qualquer rede de computador.
Outros componentes do sistema podem oferecer a funcionalidade de filirena, contanto que atendam aos requisitos mínimos para firewalls,
conforme o Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do titular do cartão para oferecer a
funcionalidade do firewall, esses dispositivos deverão ser incluídos no escopo e na avaliação do Requisito 1.
Requisito
Orientação
1.1 Definir os padrões de configuração do firewall e do roteador
que incluam o seguinte:
Firewalls e roteadores são os principais componentes da arquitetura que
controlam a entrada e a saída da rede. Esses dispositivos são software ou
hardware que bloqueiam acesso indesejado e gerenciam acesso autorizado de e
para a rede. Sem políticas e procedimentos para documentar como a equipe deve
configurar firewalls e roteadores, fica fácil uma empresa perder sua primeira linha
de defesa na proteção de dados. As políticas e os procedimentos ajudarão a
garantir que a primeira linha de defesa da organização na proteção de seus dados
continue forte.
Os ambientes virtuais onde os fluxos de dados não transitarem por uma rede
física deverão ser avaliados de forma a garantir que se obtenha a segmentação
da rede.
1.1.1 Um processo formal para aprovar e testar todas as
conexões de rede e alterações às configurações do firewall e
do roteador
Uma política e um processo para aprovar e testar todas as conexões e alterações
nos firewalls e roteadores ajudará a evitar problemas de segurança causados pela
má configuração da rede, do roteador ou do firewall.
Os fluxos de dados entre máquinas virtuais deverão ser incluídos nas políticas e
processos.
Outubro de 2010
Página 11
Requisito
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
Orientação
Os diagramas de rede permitem que a organização identifique o local de todos os
dispositivos de rede. Além disso, o diagrama de rede pode ser usado para mapear
o fluxo de dados dos dados do titular do cartão por toda a rede e entre cada
dispositivo, a fim de entender totalmente o escopo do ambiente dos dados do
titular do cartão. Sem os diagramas da rede atual e do fluxo de dados, os
dispositivos com dados do titular do cartão podem ser ignorados e sem querer
deixados de fora dos controles de segurança em camadas implementados para
PCI DSS e, assim, vulneráveis ao comprometimento.
Os diagramas de rede e fluxo de dados deverão incluir componentes do sistema
virtual e fluxos de dados trocados entre os hosts.
1.1.3 Requisitos para um firewall em cada conexão da Internet
e entre qualquer zona desmilitarizada (DMZ) e a zona da rede
interna
Usar um firewall e todas as conexões que entram e saem da rede permite que a
organização monitore e controle a entrada e saída de acesso, e minimize as
chances de um indivíduo mal-intencionado de obter acesso à rede interna.
1.1.4Descrição de grupos, funções e responsabilidades quanto
ao gerenciamento lógico dos componentes da rede
Essa descrição de funções e a atribuição da responsabilidade garante que alguém
seja claramente responsável pela segurança de todos os componentes e esteja
ciente da responsabilidade, e também que nenhum dispositivo fique sem
gerenciamento.
1.1.5 Documentação e justificativa comercial para o uso de
todos os serviços, protocolos e portas permitidas, incluindo a
documentação dos recursos de segurança implementados para
os protocolos considerados inseguros.
Exemplos de serviços, protocolos ou portas inseguros incluem
mas não são limitados a FTP, Telnet, POP3, IMAP e SNMP.
Muitas vezes ocorrem comprometimentos decorrentes de serviços e portas não
utilizados ou inseguros, visto que é freqüente eles possuírem vulnerabilidades
conhecidas – e muitas organizações estão vulneráveis a esses tipos de
comprometimentos, pois não aplicam patches nas vulnerabilidades de segurança
para serviços, protocolos e portas que não utilizam (ainda que as vulnerabilidades
ainda estejam presentes). Cada organização deve decidir claramente quais
serviços, protocolos e portas são necessários para seus negócios, documentá-los
nos registros e garantir que todos os outros serviços, protocolos e portas sejam
desabilitados ou removidos. Além disso, as organizações devem pensar em
bloquear todo o tráfego e somente reabrir essas portas depois de ser determinada
e documentada uma necessidade.
Além disso, existem muitos serviços, protocolos ou portas de que uma empresa
pode precisar (ou estarem ativados por padrão) que normalmente sejam usados
por indivíduos mal-intencionados para comprometer uma rede. Se esses serviços,
protocolos e portas inseguros forem necessários para a empresa, o risco
apresentado pelo uso desses protocolos deve ser claramente entendido e aceito
pela organização, o uso do protocolo deve ser justificado e os recursos de
segurança que permitem que esses protocolos sejam usados com segurança
deverão ser documentados e implementados. Se esses serviços, protocolos ou
portas inseguros não forem necessários para a empresa, eles deverão ser
desativados ou removidos.
Outubro de 2010
Página 12
Requisito
1.1.6 Requisito para analisar os conjuntos de regras do firewall
e do roteador pelo menos a cada seis meses
Orientação
Essa análise dá à organização a oportunidade de, pelo menos a cada seis meses,
limpar todas as regras desnecessárias, obsoletas ou incorretas, e garantir que
todos os conjuntos de regras só permitam que serviços e portas não autorizados
correspondam às justificativas de negócios.
É aconselhável fazer essas análises com mais freqüência, como mensalmente,
para garantir que os conjuntos de regras estejam atualizados e correspondam às
necessidades da empresa, sem abrir furos na segurança e correr riscos
desnecessários.
1.2 Elaborar uma configuração de firewall e do roteador que
restrinja as conexões entre redes não confiáveis e quaisquer
componentes do sistema no ambiente de dados do titular do
cartão.
Observação: Uma “rede não confiável” é qualquer rede que seja
externa às redes que pertencem à entidade em análise e/ou que
esteja além da capacidade da entidade de controlar ou gerenciar.
1.2.1 Restringir o tráfego de entrada e saída para aquele que é
necessário para o ambiente de dados do titular do cartão.
É 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.
1.2.2 Proteger e sincronizar os arquivos de configuração do
roteador.
Apesar de os arquivos de configuração de execução normalmente serem
implementados com configurações seguras, os arquivos de inicialização (os
roteadores só executam esses arquivos na reinicialização) podem não ser
implementados com as mesmas configurações seguras, pois eles só são
executados ocasionalmente. Quando o roteador for reinicializado sem as mesmas
configurações seguras que as dos arquivos de configuração de execução, o
resultado pode ser regras mais fracas que permitam que indivíduos 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.
Outubro de 2010
Página 13
Requisito
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.
Orientaçã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.
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.
1.3.1 Implemente uma DMZ para limitar o tráfego somente para
componentes do sistema que oferece serviços, protocolos e
portas acessíveis publicamente.
O 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.
1.3.2 Limitar o tráfego de entrada da Internet a endereços IP na
DMZ.
A interrupção das conexões de IP oferecem uma oportunidade para inspeção e
restrição de fontes/destinos, ou inspeção/bloqueio do contúdo, evitando assim o
acesso não filtrado entre pessoas não confiáveis e ambientes confiáveis.
1.3.3Não permitir a entrada ou saída de nenhuma rota direta
com relação ao tráfego entre a Internet e o ambiente de dados
do titular do cartão.
A interrupção das conexões de IP oferecem uma oportunidade para inspeção e
restrição de fontes/destinos, ou inspeção/bloqueio do contúdo, evitando assim o
acesso não filtrado entre pessoas não confiáveis e ambientes confiáveis. Isto
ajudará a evitar, por exemplo, que indivídos mal-intencionados enviem dados
obtidos na rede para um servidor externo não confiável em uma rede não
confiável
Outubro de 2010
Página 14
Requisito
1.3.4 Não permitir que endereços internos sejam transmitidos
via Internet na DMZ.
Orientação
Normalmente um pacote contém os endereços de IP do computador que
originalmente o enviou, permitindo que os outros computadores da rede saibam
de onde ele vem. Em certos casos, esse endereço de IP de envio sofrerá spoofing
por indivíduos mal-intencionados.
Por exemplo: indivíduos mal-intencionados enviam um pacote com um endereço
spoof, para que (a menos que seu firewall proíba) o pacote consiga entrar na sua
rede pela Internet, parecendo que se trata de um tráfego interno e, portanto,
legítimo. Quando o indivíduo mal-intencionado estiver dentro da sua rede, ele
poderá começar a comprometer seus sistemas.
A filtragem ingressa é uma técnica que você pode usar no seu firewall para filtrar
pacotes que entram na sua rede, como, entre outras coisas, garantindo que os
pacotes não sofram spoofing, parecendo que vêm de sua própria rede interna.
Para obter mais informações sobre a filtragem de pacotes, pense em obter
informações sobre uma técnica complementar chamada “filtragem egressa”.
1.3.5Não permitir o tráfego de saída não autorizado do
ambiente de dados do titular do cartão para a Internet.
Todo tráfego que sair do ambiente de dados do titular do cartão deverá ser
avaliado para garantir que o tráfego de saída esteja de acordo com as regras
autorizadas preestabelecidas. As conexões deverão ser inspecionadas para
retringir o tráfego de forma a permitir apenas as comunicações autorizadas (por
exemplo restringindo portas/endereços de origem/destino ou bloqueando o
conteúdo).
Onde não forem permitidas conexões de entrada, as conexões de saída poderão
ser alcançadas através de arquiteturas ou componentes de sistema que
interrompam e inspecionem a conexão de IP.
1.3.6 Implementar inspeção com status, também conhecida
como filtragem de pacote dinâmico. (Ou seja, somente
conexões "estabelecidas" são permitidas na rede.)
Um firewall que executa inspeção de pacotes com status mantém o “status” (ou
estado) de cada conexão para o firewall. Ao manter o "status”, o firewall sabe se o
que parece ser uma resposta a uma conexão anterior é de fato uma resposta
(visto que isso “lembra” a conexão anterior) ou se trata-se de um indivíduo ou
software mal-intencionado tentando fazer spoofing ou enganar o firewall para
permitir a conexão.
1.3.7 Implementar os componentes do sistema que armazenam
dados do titular do cartão (como banco de dados) em uma
zona da rede interna, separada da DMZ e de outras redes não
confiáveis.
Os dados do titular do cartão exigem o mais alto nível de proteção de
informações. Se os dados do titular do cartão estiverem localizados dentro da
DMZ, o acesso a essas informações será mais fácil para um atacante externo,
pois há poucas camadas a serem penetradas.
Observação: a intenção deste requisito não inclui armazenamento em memória
volátil.
Outubro de 2010
Página 15
Requisito
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.
Orientação
É 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.
Outubro de 2010
Página 16
Requisito 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
Orientação
2.1 Sempre alterar os padrões disponibilizados pelo fornecedor
antes de instalar um sistema na rede—por exemplo, incluir
senhas, strings de comunidade de SNMP (simple network
management protocol) e a eliminação de contas desnecessárias.
Indivíduos mal-intencionados (dentro e fora de uma empresa) com freqüência
usam senhas padrão do fornecedor e outras configurações padrão do fornecedor
para comprometer os sistemas. Essas configurações são conhecidas nas
comunidades de hackers e deixam seu sistema altamente vulnerável a ataques.
2.1.1Em ambientes sem fio conectados ao ambiente de
dados do titular do cartão ou que transmitam dados do titular
do cartão, alterar os padrões do fornecedor sem fio, incluindo,
mas não se limitando a, chaves de criptografia sem fio padrão,
senhas e strings de comunidades de SNMP.
Muitos usuários instalam esses dispositivos sem aprovação da gerência e não
alteram as configurações-padrão nem fazem as configurações de segurança. Se
as redes wireless não forem implementadas com configurações de segurança
suficientes (incluindo a alteração das configurações-padrão), os sniffers da rede
wireless conseguem espreitar o tráfego, capturar dados e senhas e entrar e atacar
sua rede com facilidade. Além disso, o protocolo de troca de chaves para a versão
antiga da criptografia o 802.11x (WEP) foi quebrado e pode tornar a criptografia
inútil. Verifique se o firmware dos dispositivos está atualizado para suportar
protocolos mais seguros (por exemplo, WPA2).
2.2 Desenvolver padrões de configuração para todos os
componentes do sistema. Certificar-se de que esses padrões
abrangem todas as vulnerabilidades de segurança conhecidas e
estão em conformidade com os padrões de fortalecimento do
sistema aceitos pelo setor.
Existem pontos fracos conhecidos em vários sistemas operacionais, bancos de
dados e aplicativos empresariais, e existem também formas conhecidas de
configurar esses sistemas para corrigir as vulnerabilidades de segurança. Para
ajudar quem não é especialista nisso, as organizações de segurança criaram
recomendações para proteção do sistema que aconselham como corrigir esses
pontos fracos. Se os sistemas forem deixados com esses pontos fracos, como por
exemplo configurações de arquivo fracas ou serviços e protocolos com falhas
(para aqueles serviços e protocolos que não são necessários com freqüência), um
transgressor poderá usar várias e conhecidas explorações para atacar serviços e
protocolos vulneráveis e, assim, ganhar acesso à rede da organização. Websites
de origem onde você poderá aprender sobre as melhores práticas da indústria que
poderão ajudá-lo a implantar padrões de configuração incluindo, mas não apenas:
www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org.
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)
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.
Outubro de 2010
Página 17
Requisito
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.
Orientação
Isso serve para garantir que os padrões de configuração do sistema da sua
organização e os processos relacionados abordem funções do servidor que
precisem ter níveis de segurança diferentes ou que possam introduzir pontos
fracos de segurança em outras funções do mesmo servidor. Por exemplo:
1. Um banco de dados que precise ter medidas de segurança robustas estaria
arriscado a compartilhar um servidor com um aplicativo da Web, que precisa
ser aberto e interagir diretamente com a Internet.
2. A não-aplicação de um patch em uma função aparentemente pequena pode
resultar em comprometimento que cause impacto em outras funções mais
importantes (como um banco de dados) no mesmo servidor.
Este requisito poderá ser utilizado em todos os servidores do ambiente de dados
do titular do cartão (geralmente com base em Unix, Linux ou Windows). Este
requisito não deverá ser aplicado em sistemas que originalmente implantem níveis
de segurança em um único servidor (ex.: mainframe).
Onde forem utilizadas tecnologias de virtualização, cada componente virtual (ex.:
máquina virtual, comutador virtual, aplicativo de segurança virtual, etc) deverá ser
considerado delimitador "de sistema". Os hipervisores individuais poderão ser
compatíveis com diversas funções, mas uma única máquina virtual deveria aderir
à regra "uma função primária". Nestas circunstâncias, o comprometimento do
hipervisor poderá levar ao comprometimento de todas as funções do sistema.
Consequentemente, o nível de risco também deverá ser considerado ao localizar
diversas funções ou componentes em um único sistema físico.
2.2.2 Ativar somente serviços, protocolos, daemons, etc.
necessários e seguros, conforme exigido para a função do
sistema.
Implantar recursos de segurança para todos os serviços,
protocolos ou daemons exigidos que forem considerados não
seguros. Por exemplo: utilizar tecnologias como SSH, S-FTP,
SSL ou IPSec VPN para proteger sistemas como NetBIOS,
compartilhamento de arquivos, Telnet, FTP, etc.
2.2.3 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.
Outubro de 2010
Página 18
Requisito
Orientação
2.2.4 Remover todas as funcionalidades desnecessárias, como
scripts, drivers, recursos, subsistemas, sistemas de arquivo e
servidores da Web desnecessários.
Os padrões de proteção do servidor devem incluir processos para resolver
funcionalidades desnecessárias com implicações de segurança específicas (como
remover/desativar FTP ou o servidor da Web, caso o servidor não execute essas
funções).
2.3 Criptografar todo o acesso administrativo não console
durante a criptografia robusta. Usar tecnologias como SSH, VPN
ou SSL/TLS para o gerenciamento baseado na Web e outros
acessos administrativos não-console.
Se a administração remota não for feita com autenticação segura e comunicações
criptografadas, informações confidenciais de nível administrativo ou operacional
(como as senhas do administrador) poderão ser reveladas a um espião. Um
indivíduo mal-intencionado pode usar essas informações para acessar a rede,
tornar-se administrador e roubar os dados.
2..4Os provedores de hospedagem compartilhada devem
proteger cada ambiente hospedado da entidade e os dados do
titular do cartão. Esses provedores devem atender a requisitos
específicos, conforme detalhado no Apêndice A: Requisitos
adicionais do PCI DSS para provedores de hospedagem
compartilhada.
Isso serve para provedores de hospedagem que oferecem ambientes de
hospedagem compartilhada para vários clientes no mesmo servidor. Quando
todos os dados estiverem no mesmo servidor e sob controle de um único
ambiente, muitas vezes essas configurações nesses servidores compartilhados
não serão gerenciáveis por clientes individuais, permitindo que os clientes
adicionem funções e scripts inseguros que causam impacto na segurança de
todos os outros ambientes de clientes e, assim, facilitando para um indivíduo malintencionado comprometer os dados de um cliente, obtendo acesso a todos os
dados dos outros clientes. Veja o Anexo A.
Outubro de 2010
Página 19
Orientação 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 e-mails não criptografados.
Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS para obter definições de "criptografia robusta" e outros termos do
PCI DSS.
Requisito
Orientação
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.
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.
3.1.1 Implementar uma política de retenção e descarte de
dados que inclua:
Limite da quantia de dados armazenados e do tempo de
retenção ao que é exigido pelos requisitos legais,
regulatórios e comerciais
Processos para exclusão segura de dados quando não
mais necessários
Requisitos de retenção específicos para dados de titular do
cartão
Processos trimestrais manuais ou automáticos para
identificar e excluir com segurança os dados do titular do
cartão que excederem os requisitos de retenção definidos
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!
Outubro de 2010
Página 20
Requisito
Orientação
3.2 Não armazenar dados de autenticação confidenciais após a
autorização (mesmo se estiverem criptografados).
Os dados confidenciais de autenticação consistem em dados de tarja magnética
(ou trilha)6, código de validação do cartão ou valor7, e dados de PIN8. O
armazenamento de dados de autenticação confidenciais após a autorização
é proibido! Esses dados são muito valiosos para indivíduos mal-intencionados,
pois permitem falsificar cartões de pagamento falsos e criar transações
fraudulentas. Veja Glossário de termos, abreviações e acrônimos do PCI DSS e
PA-DSS para obter a definição completa de “dados de autenticação confidenciais”.
Os dados de autenticação confidenciais incluem os dados
conforme mencionados nos seguintes Requisitos 3.2.1 até 3.2.3:
Observação:É permissível para os emissores e empresas que
suportam os serviços de emissão para armazenar dados de
autenticação sensível se houver justificação de negócios e se os
dados forem armazenados com segurança.
3.2.1 Não armazenar o conteúdo completo de qualquer rastro
da tarja magnética (localizada na parte posterior do cartão, em
um chio ou outro local). Esses dados são denominados
alternativamente como rastro completo, rastro, rastro 1, rastro 2
e dados da tarja magnética.
Observação: As empresas que executam, facilitam ou suportam serviços de
emissão têm permissão para armazenar dados de autenticação confidenciais
SOMENTE SE apresentarem legítima necessidade de negócios para armazenar
esses dados. Deve-se observar que todos os requisitos de PCI DSS se aplicam
aos emissores, e a única exceção para emissores e processadores de emissões é
que os dados de autenticação confidenciais poderão ficar retidos se houver uma
razão legítima para tanto. Razão legítima é aquela necessária para o desempenho
da função fornecida para o emissor e não de conveniência.
Esses dados deverão ser armazenados com segurança e de acordo com o PCI
DSS e os requisitos específicos da bandeira de débito.
Se for armazenado o rastro inteiro, indivíduos mal-intencionados que obtiverem
esses dados poderão reproduzir e vender cartões de pagamento.
Observação: No curso normal dos negócios, os seguintes
elementos de dados da tarja magnética talvez precisem ser
retidos:
O número da conta principal (PAN)
Data de vencimento
O código de serviço
Para minimizar o risco, armazene somente os elementos de
dados conforme necessário para os negócios.
6
7
8
Dados codificados na tarja magnética utilizados para autorização durante a transação com o cartão. Estes dados também poderão ser encontrados em um chip ou em outra parte
do cartão. As entidades não podem manter todos os dados da tarja magnética após a autorização da transação. Os únicos elementos dos dados da tarja que podem ser retidos
são o número da conta principal, o nome do titular do cartão, a data de vencimento e o código de serviço.
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.
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.
Outubro de 2010
Página 21
Requisito
Orientação
3.2.2 Não armazenar o código ou valor de verificação do cartão
(o número de três ou quatro dígitos impresso na frente ou atrás
do cartão de pagamento) usado para verificar as transações
com cartão não presente.
O objetivo do código de validação do cartão é proteger as transações do tipo
"cartão não-presente", aquelas feitas por Internet, por correio ou telefone
(MO/TO), nas quais o consumidor e o cartão não estão presentes. Esses tipos de
transação podem ser autenticadas como originadas do proprietário do cartão
somente ao solicitar esse código de validação do cartão, pois o proprietário do
cartão o tem em mãos e pode ler o valor. Se esses dados proibidos forem
armazenados e depois roubados, indivíduos mal-intencionados podem executar
transações fraudulentas pela Internet e por MO/TO.
3.2.3 Não armazenar o PIN (personal identification number) ou
o bloco de PIN criptografado.
Esses valores só devem ser conhecidos pelo proprietário do cartão ou pelo banco
que emitiu o cartão. Se esses dados proibidos forem armazenados e depois
roubados, indivíduos mal-intencionados podem executar transações de débito
protegidas por senha (por exemplo, saques em caixas eletrônicos).
3.3 Mascarar o PAN quando exibido (os primeiros seis e quatro
últimos dígitos são o número máximo de dígitos a serem
exibidos).
Observações:
Esse requisito não se aplica aos funcionários e outras
partes interessadas em um negócio legítimo que precisam
visualizar o PAN completo.
Este requisito não substitui os requisitos mais rigorosos em
vigor quanto às exibições dos dados do titular do cartão por exemplo, para recebimentos do ponto de venda.
A exibição do PAN completo em locais como telas de computador, recibos de
cartão de pagamento, faxes ou extratos em papel pode fazer com que esses
dados sejam obtidos por indivíduos não autorizados e usados de forma
fraudulenta. O PAN pode ser exibido em sua integridade nos recibos do tipo “cópia
do comerciante”; no entanto, os recibos em papel devem obedecer aos mesmos
requisitos de segurança que as cópias eletrônicas e seguir as diretrizes do Padrão
de segurança de dados do PCI, especialmente o Requisito 9, sobre segurança
física. O PAN completo também pode ser exibido para as pessoas com
necessidade de negócios legítima de ver o PAN completo.
Este requisito está relacionado à proteção do PAN exibida em telas, recibos, etc, e
não deverá ser confundido com o Requisito 3.4 para proteção do PAN quando
armazenado em arquivos, bancos de dados, etc.
Outubro de 2010
Página 22
Requisito
Orientação
3.4Tornar o PAN ilegível em qualquer local onde ele esteja
armazenado (inclusive em mídia digital portátil, mídia de back-up,
em registros) utilizando qualquer uma das seguintes abordagens:
Referências únicas com base na criptografia robusta (o
hash deve ser do PAN inteiro)
Truncamento (o hashing não pode ser usado para substituir
o segmento truncado do PAN)
Tokens de índice e pads (os pads devem ser armazenados
de forma segura)
Criptografia robusta com processos e procedimentos de
gerenciamento de chaves associados
A falta de proteção dos PANs pode permitir que indivíduos mal-intencionados
visualizem ou façam download desses dados. Os PANs armazenados no
armazenamento principal (bancos de dados ou arquivos simples, como arquivos
de texto e planilhas), além de armazenamento não principal (backup, logs de
auditoria, logs de exceção ou de resolução de problemas) devem todos estar
protegidos. Danos decorrentes de roubou ou perda de tarjas de backup durante o
transporte poderão ser reduzidos ao garantir que os PANs sejam deixados
ilegíveis por meio de criptografia, truncamento ou codificação hash. Como os logs
de auditoria, resolução de problemas e de exceção precisam ser retidos, você
pode evitar a divulgação dos dados nos logs ao deixar os PANs ilegíveis (ou
removendo-os) em logs.
Observação: É um esforço relativamente simples para um
indivíduo mal-intencionado reconstituir os dados do PAN original
caso tenha acesso às versões truncadas e hash do PAN.
Quando as versões truncada e hash do mesmo PAN estiverem
presentes no ambiente de uma entidade, os controles adicionais
deverão estar implantados para assegurar que as versões
truncada e hash não sejam correlacionadas para reconstituir o
PAN original.
Referências únicas com base na criptografia robusta (o
hash deve ser do PAN inteiro)
Ao correlacionar as versões de hash e truncada de um determinado PAN, um
indivíduo mal-intencionado poderá facilmente derivar o valor do PAN original. Os
controles que evitam a correlação desses dados ajudarão a garantir que o PAN
original permaneça ilegível.
Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS e
PA-DSS para obter definições de "criptografia robusta" e outros termos do PCI
DSS.
As funções de sentido único, como o Algoritmo de has protegido (SHA - Secure
Hash Algorithm) com base em criptografia robusta poderão ser utilizadas para
tornar ilegíveis os dados do titular do cartão. As funções de hashing são
adequadas quando não houver necessidade de recuperar o número original (o
hashing de direção única é irreversível).
Para complicar a criação de tabelas de arco íris é recomendável, mas não
necessário, que seja inserido um valor de sal à função de hash além do PAN.
Truncamento (o hashing não pode ser usado para substituir
o segmento truncado do PAN)
A intenção do truncamento é que somente uma parte (sem exceder os primeiro
seis e os últimos quatro dígitos) do PAN seja armazenado. Isso é diferente do
mascaramento, no qual o PAN inteiro é armazenado, mas isso ocorre quando ele
é exibido (ou seja, somente parte do PAN é exibido em telas, relatórios, recibos,
etc.).
Este requisito está relacionado à proteção do PAN quando armazenado em
arquivos, bancos de dados, etc, e não deverá ser confundido com o Requisito 3.3
para proteção do PAN exibido em telas, recibos, etc.
Outubro de 2010
Página 23
Requisito
Orientação
Tokens de índice e pads (os pads devem ser armazenados
de forma segura)
Os tokens de índice e pads também podem ser usados para tornar os dados do
titular do cartão ilegíveis. Um token de índice é um token criptográfico que
substitui o PAN, com base em determinado índice para um valor imprevisível. Um
pad de uso único é um sistema no qual uma chave privada, gerada
aleatoriamente, é usada só uma vez para criptografar uma mensagem que então é
descodificada usando um pad e uma chave de uso único correspondentes.
Criptografia robusta com processos e procedimentos de
gerenciamento de chaves associados
O objetivo da criptografia robusta (veja a definição e os comprimentos da chave no
documento Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS)
é que a criptografia se baseie em um algoritmo testado e aceito pela empresa (e
não um algoritmo “feito em casa”).
3.4.1 Se a criptografia de disco for utilizada (em vez da
criptografia de bancos de dados no nível de arquivo ou coluna),
o acesso lógico deve ser gerenciado independentemente de
mecanismos de controle de acesso a sistemas operacionais
nativos (por exemplo, não utilizando bancos de dados de
contas de usuário locais). As chaves da descrição não devem
estar ligadas às contas de usuário.
O objetivo deste requisito é abordar a aceitabilidade da criptografia de disco para
deixar os dados do titular do cartão ilegíveis. A criptografia de disco codifica os
dados armazenados no armazenamento em massa do computador e descodifica
automaticamente as informações quando um usuário autorizado as solicita. Os
sistemas de criptografia de disco interceptam as operações de leitura e gravação
do sistema operacional e executam as transformações criptográficas adequadas
sem nenhuma ação especial por parte do usuário, além de fornecer uma senha ou
passphrase no início de uma sessão. Com base nessas características de
criptografia de disco, para obedecer a esse requisito, o método de criptografia de
disco não pode ter:
1) Associação direta com o sistema operacional, ou
2) Chaves de decodificação que estejam associadas a contas de usuários.
3.5 Proteja qualquer chave usada para tornar os dados do titular
do cartão seguros contra divulgação e mal uso:
Observação: Esse requisito também se aplica a chaves de
criptografia de chaves usadas para proteger as chaves de
criptografia de dados - tais chaves de criptografia de chaves
devem ser ao menos tão robustas quanto as chaves de
criptografia de dados.
3.5.1Restringir o acesso às chaves criptográficas ao menor
número necessário de responsáveis pela proteção.
As chaves criptográficas devem ser muito bem protegidas, pois quem tiver acesso
a elas conseguirá decodificar os dados. As chaves de criptografia de chaves, se
utilizadas, deverão ser ao menos tão robustas quanto as chaves de criptografia de
dados para garantir a proteção adequada da chave que criptografa os dados e dos
dados criptografados por essa chave.
O requisito para proteger chaves da divulgação e do uso indevido se aplica tanto
às chaves de criptografia de dados quanto às chaves de criptografia de chaves.
Como uma chave de criptografia de chaves poderá conceder direito de acesso a
várias chaves de criptografia de dados, as chaves de criptografia de chaves
necessitam de medidas de proteção vigorosas. Os métodos de armazenamento
seguro das chaves de criptografia de chaves incluem, mas não limitam-se a,
módulos de segurança de hardware (HSMs) e adulteram o armazenamento
evidente com controle e divisão de conhecimento.
Deve haver muito poucas pessoas com acesso às chaves criptográficas,
normalmente só aquelas com responsabilidades de custódia de chaves.
Outubro de 2010
Página 24
Requisito
3.5.2 Armazenar chaves criptográficas de forma segura no
menor número possível de locais e formatos.
3.6 Documentar e implementar por completo todos os processos
e procedimentos de gerenciamento de chave com relação às
chaves criptográficas usadas para a criptografia dos dados do
titular do cartão, incluindo o seguinte:
Orientação
As chaves criptográficas devem ser armazenadas em segurança, normalmente
criptografas com chaves de criptografia e armazenadas em muito poucos locais.
As chaves de criptografia de chaves não precisarão ser criptografadas, mas
deverão ficar protegidas contra divulgação e uso indevido da forma definida no
Requisito 3.5. Armazenar as chaves de criptografia de chaves em locais físicos ou
logicamente separados das chaves de criptografia de dados reduz os riscos de
acesso não autorizado às duas chaves.
A forma como as chaves criptográficas são gerenciadas é parte essencial da
segurança continuada da solução de criptografia. Um bom processo de
gerenciamento de chaves, seja ele manual ou automatizado, como parte do
produto de criptografia, aborda todos os elementos de chave, de 3.6.1 a 3.6.8.
Observação: Vários padrões do setor para o gerenciamento de
chave estão disponíveis a partir de diversos recursos, incluindo
NIST, que pode ser encontrado em http://csrc.nist.gov.
3.6.1 Geração de chaves criptográficas robustas
A solução de criptografia deve gerar chaves robustas, conforme definido em
Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS, em
"Criptografia robusta".
3.6.2 Distribuição segura da chave criptográfica
A solução de criptografia deve distribuir as chaves de forma segura, o que
significa que as chaves não deve ser distribuídas sem limitação, e sim somente
para os responsáveis identificados em 3.5.1.
3.6.3 Armazenamento seguro de chaves criptográficas
A solução de criptografia deve armazenar as chaves com segurança, o que
significa que as chaves não devem ser armazenadas sem limitação (criptografe-as
com uma chave de criptografia).
Outubro de 2010
Página 25
Requisito
3.6.4 Troca de chave criptográfica para as chaves que
chegaram ao final de seu criptoperíodo (por exemplo, após ter
passado determinado período de tempo e/ ou após certa
quantidade de texto cifrado ter sido produzido por dada chave),
conforme definido pelo fornecedor associado do aplicativo ou o
dono da chave e com base nas melhores práticas e
orientações do setor (por exemplo, a Publicação Especial NIST
800-57).
Orientação
Criptoperíodo é o tempo transcorrido durante o qual uma determinada chave de
criptografia poderá ser utilizada para seus devidos fins. As considerações para
definir o criptoperíodo incluem, mas não apenas, a força do algoritmo em
destaque, o tamanho ou o comprimento da chave, o risco de comprometimento da
chave e a confidencialidade dos dados a serem criptografados.
A troca periódica das chaves de criptografia é essencial para minimizar o risco de
alguém obter as chaves de criptografia e conseguir decodificar os dados.
Caso seja fornecido pelo revendedor do aplicativo de criptografia, siga os
processos e recomendações documentados pelo revendedor para troca periódica
das chaves. O proprietário ou responsável pela chave também poderá consultar
as melhores práticas da indústria sobre algoritmos de criptografia e gerenciamento
de chaves, por exemplo a Publicação especial NIST 800-57, para obter
orientações sobre o criptoperíodo adequado de diferentes algoritmos e
comprimentos de chaves.
A inteção deste requerimento se aplica às chaves utilizadas para criptografar os
dados do titular do cartão armazenados e a qualquer chave de criptografia de
chaves.
3.6.5 Inutilização ou substituição (por exemplo, arquivamento,
destruição e/ ou revogação) de chaves considerada necessária
quando a integridade da chave estiver enfraquecida (por
exemplo, saída de um funcionário de uma chave de texto
simples) ou houver suspeita de que a chave esteja
comprometida.
Observação: Caso chaves criptográficas inutilizadas ou
recolocadas precisarem ser retidas, essas chaves deverão ser
arquivadas em segurança (por exemplo, usando uma chave de
criptografia de chaves). Chaves criptográficas arquivadas
devem ser usadas somente para fins de
decodificação/verificação.
Chaves antigas que não são mais usadas nem necessárias devem ser
aposentadas e destruídas para garantir que não possam mais ser usadas. Se for
necessário mantê-las (para usar com dados arquivados e criptografados, por
exemplo), elas deverão ser muito bem protegidas (veja o item 3.6.6 abaixo). A
solução de criptografia também deve levar em consideração e facilitar o processo
para substituir as chaves que estejam sabidamente ou potencialmente
comprometidas.
Outubro de 2010
Página 26
Requisito
3.6.6 Se forem usadas operações manuais de gerenciamento
de chave criptográfica de texto simples, essas operações
devem ser gerenciadas com o uso de conhecimento separado
e de controle duplo (por exemplo, exigindo duas ou três
pessoas, cada uma conhecendo somente o seu componente da
chave, para reconstituir a chave completa).
Orientação
O conhecimento compartilhado e o controle duplo das chaves são usados para
eliminar a possibilidade de uma pessoa ter acesso à chave inteira. Este controle
pode ser aplicado em operações de gerenciamento de chaves manual onde o
gerenciamento de chaves não for implantado por um produto de criptografia.
Observação: Exemplos de operações manuais de
gerenciamento de chave incluem, mas não são limitados a:
geração de chave, transmissão, carregamento, armazenamento
e destruição.
3.6.7 Prevenção contra a substituição não autorizada de
chaves criptográficas.
A solução de criptografia não deve levar em conta nem aceitar a substituição de
chaves vindas de fontes não autorizadas ou de processos inesperados.
3.6.8 Requisito para que os responsáveis pela proteção das
chaves criptográficas assinem um formulário declarando que
eles compreendem e aceitam suas responsabilidades pela
proteção das chaves.
Este processo assegurará que indivíduos que atuem como responsáveis se
comprometam com a função de responsáveis pela chave e conheçam as
obrigações.
Outubro de 2010
Página 27
Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas
As informações confidenciais devem ser criptografadas durante a transmissão nas redes que são facilmente acessadas por indivíduos malintencionados. Redes wireless configuradas de forma incorreta e vulnerabilidades na criptografia legada e protocolos de autenticação continuam
a ser alvos contínuos de indivíduos mal-intencionados que exploram essas vulnerabilidades para obter acesso privilegiado aos ambientes de
dados do titular do cartão.
Requisito
Orientação
4.1 Uso de protocolos robustos de criptografia e de segurança
(por exemplo, SSL/TLS, IPSEC, SSH, etc.) para proteger dados
confidenciais do titular do cartão durante a transmissão por redes
públicas, abertas.
Os exemplos de redes abertas e públicas que estão no escopo
do PCI DSS incluem mas não se limitam a:
A Internet
Tecnologias sem fio,
Global System for Mobile communications (GSM)
General Packet Radio Service (GPRS).
As informações confidenciais devem ser criptografas durante a transmissão por
redes públicas, pois é fácil e comum para um indivíduo mal-intencionado
interceptar e/ou desviar os dados enquanto eles estiverem em trânsito.
Por exemplo: o protocolo de camada de sockets segura (SSL - Secure Sockets
Layer) criptografa páginas da web e os dados inseridos nelas. Ao usar sites
protegidos por SSL, verifique se “https” faz parte do URL.
Observe que algumas implantações de protocolo (como SSL versão 2.0 e SSH
versão 1.0) possuem vulnerabilidades documentadas, como superfluxos de buffer,
que um transgressor poderá utilizar para obter o controle do sistema afetado.
Qualquer que seja o protocolo de segurança adotado, verifique que esteja
configurado para utilizar somente configurações e versões seguras para evitar que
seja utilizada uma conexão não segura.
Outubro de 2010
Página 28
Requisito
4.1.1 Certificar-se de que as redes wireless estejam
transmitindo dados do titular do cartão ou estejam conectadas
ao ambiente de dados do titular do cartão, usar as melhores
práticas do setor (por exemplo, IEEE 802.11i) para implementar
a criptografia robusta para a autenticação e a transmissão.
Observação: O uso de WEP como controle de segurança foi
proibido em 30 de junho de 2010.
Orientação
Usuários mal-intencionados usam as várias ferramentas que estão disponíveis
gratuitamente para espionar as comunicações wireless. O uso de criptografias
robustas poderá limitar a divulgação de informações confidenciais através da rede.
Muitos comprometimentos conhecidos dos dados do titular do cartão
armazenados somente em uma rede com fio foram originados quando um usuário
mal-intencionado expandiu o acesso de uma rede wireless insegura. Exemplos de
implantações sem fio que necessitam de criptografia robusta incluem, mas não
limitam-se a, GPRS, GSM, WIFI, satélites e Bluetooth.
A criptografia robusta para autenticação e transmissão dos dados do titular do
cartão é necessária para evitar que usuários mal-intencionados obtenham acesso
à rede wireless – os dados na rede – ou utilizem as redes wireless para chegar a
outros dados ou redes internos. A criptografia WEP nunca deverá ser utilizada
como único meio de dados de criptografia em um canal sem fio, pois não é
considerada uma criptografia robusta. É vulnerável devido aos fracos vetores de
inicialização no processo de troca de chaves WEP e não possui a rotação de
chaves necessária. Um transgressor pode usar as ferramentas de cracking por
força bruta amplamente disponíveis para penetrar na criptografia por WEP.
Os dispositivos sem fio atuais deverão ser atualizados (exemplo: atualizar o
firmware de ponto de acesso para WPA2) para que sejam compatíveis com
criptografias robustas. Caso os dispositivos atuais não possam ser atualizados,
será possível adquirir um novo equipamento ou outros controles de compensação
implantados para fornecer criptografia robusta.
4.2Nunca enviar PANs não criptografados por tecnologias de
envio de mensagens de usuário final (por exemplo, e-mail,
sistemas de mensagens instantâneas, bate-papo).
E-mail, sistemas de mensagens instantâneas, bate-papo podem ser facilmente
interceptados por sniffing de pacotes durante a entrega transversal por redes
internas e públicas. Não utilize essas ferramentas de envio de mensagem para
enviar o PAN se elas não tiverem recurso de criptografia.
Outubro de 2010
Página 29
Orientação para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades
Requisito 5: Usar e atualizar regularmente o software ou programas antivírus
Softwares mal-intencionados, normalmente chamados de "malware" – incluindo vírus, worms e cavalos de Tróia – adentram a rede durante
muitas atividades de negócios aprovadas, incluindo e-mail dos funcionários e uso da Internet, computadores móveis e dispositivos de
armazenamento, resultando na exploração das vulnerabilidades do sistema. Softwares anti-vírus devem ser usados em todos os sistemas
comumente afetados por malwares para protegê-los das ameaças de softwares atuais e em evolução.
Requisito
Orientação
5.1Implementar softwares antivírus em todos os sistemas
normalmente afetados por softwares mal-intencionados
(especialmente em computadores pessoais e servidores).
Existe um fluxo constante de ataques usando façanhas amplamente divulgadas,
muitas vezes do tipo "zero day" (publicado e divulgado por redes em até uma hora
após a descoberta) contra sistemas até então seguros. Sem um software antivírus
que seja atualizado regularmente, essas novas formas de software mal-intencionado
podem atacar e desativar sua rede.
Softwares mal-intencionados podem ser baixados e/ou instalados pela Internet sem
você saber, mas os computadores também estão vulneráveis ao usarem dispositivos
removíveis de armazenamento, como CDs e DVDs, USB memory sticks e discos
rígidos, câmeras digitais, assistentes pessoais (PDAs) e outros periféricos. Sem a
instalação de um software antivírus, esses computadores podem se tornar ponto de
acesso para sua rede e/ou mirar nas informações dentro da rede.
Apesar de os sistemas comumente afetados por softwares mal-intencionados
normalmente não incluírem mainframes e a maioria dos sistemas Unix (veja mais
detalhes abaixo), cada entidade deve ter um processo de acordo com o Requisito de
PCI DSS 6.2 para identificar e resolver novas vulnerabilidade de segurança e
atualizar os padrões e processos de configuração de acordo. Se outro tipo de
solução se dirigir a ameaças idênticas com uma metodologia diferente da
abordagem com base em assinatura, ainda poderá ser aceita para atender ao
requisito.
As tendências em softwares mal-intencionados relacionadas aos sistemas
operacionais que a entidade usa devem ser incluídas na identificação de novas
vulnerabilidades de segurança, e os métodos para resolver novas tendências devem
ser incorporados aos padrões de configuração da empresa e aos mecanismos de
proteção, conforme necessário.
Em geral, os sistemas operacionais a seguir não são normalmente afetados por
software mal-intencionados: mainframes e alguns servidores Unix (como AIX,
Solaris e HP-Unix). No entanto, as tendências do setor para softwares malintencionados podem mudar rapidamente, e cada organização deve obedecer ao
Requisito 6.2 para identificar e resolver novas vulnerabilidades de segurança e
Outubro de 2010
Página 30
Requisito
5.1.1 Certificar-se de que todos os programas antivírus
podem detectar, remover e proteger contra todos os tipos
conhecidos de softwares mal-intencionados.
5.2 Certificar-se de que todos os mecanismos antivírus estejam
atualizados, funcionem ativamente e possam gerar registros de
auditoria.
Orientação
atualizar os padrões e processos de configuração de acordo.
É importante proteger contra TODOS os tipos e formas de softwares malintencionados.
O melhor software antivírus tem eficácia limitada se não tiver assinaturas antivírus
atualizada ou se não estiver ativo na rede ou no computador de uma pessoa.
Os logs de auditoria oferecem a capacidade de monitorar a atividades do vírus e as
reações do antivírus. Dessa forma, o software antivírus deverá obrigatoriamente ser
configurado de forma a gerar logs de auditoria, e esses logs deverão ser
gerenciados de acordo com o Requisito 10.
Outubro de 2010
Página 31
Requisito 6: Desenvolver e manter sistemas e aplicativos seguros
Indivíduos inescrupulosos usam as vulnerabilidades da segurança para obter acesso privilegiado aos sistemas. Muitas dessas vulnerabilidades
são solucionadas pelos patches de segurança disponibilizados pelos fornecedores, que devem ser instalados pelas entidades que gerenciam os
sistemas. Todos os sistemas críticos devem contar com os patches de software adequados lançados mais recentes para proteger contra a
exploração e o comprometimento dos dados do titular do cartão por indivíduos e softwares mal-intencionados.
Observação: Patches de software adequados são aqueles patches que foram avaliados e testados de forma suficiente para determinar se os
patches não entram em conflito com as configurações de segurança existentes. Para aplicativos desenvolvidos internamente, diversas
vulnerabilidades podem ser evitadas ao utilizar processos de desenvolvimento do sistema padrão e técnicas de codificação seguras.
Requisito
Orientação
6.1 Certificar-se de que todos os componentes do sistema e
softwares estão protegidos de vulnerabilidades conhecidas pois
têm os patches de segurança mais recentes disponibilizados
pelos fornecedores instalados. Instalar patches de segurança
críticos em até um mês após o lançamento.
Existe uma quantidade considerável de ataques usando façanhas amplamente
divulgadas, muitas vezes do tipo “zero day” (publicadas em até uma hora) contra
sistemas até então protegidos. Sem implementar os patches mais recentes nos
sistemas críticos assim que possível, um indivíduo mal-intencionado pode usá-las
para atacar e desativar a rede. Pense em priorizar mudanças de forma que
patches de segurança críticos em sistemas essenciais ou em risco possam ser
instalados em até 30 dias, e outras mudanças menos arriscadas sejam instaladas
em 2-3 meses.
Observação: Uma empresa talvez considere utilizar uma
abordagem baseada nos riscos para priorizar suas instalações
de patches. Por exemplo, ao priorizar mais a infra-estrutura
crítica (por exemplo, dispositivos e sistemas disponibilizados ao
público, bancos de dados) em vez de dispositivos internos menos
críticos, para assegurar que sistemas e dispositivos de prioridade
elevada sejam resolvidos em um mês e dispositivos e sistemas
menos críticos em três meses.
Outubro de 2010
Página 32
Requisito
Orientação
6.2 Estabelecer um processo para identificar e designar um
ranking de risco para as vulnerabilidades de segurança recémdescobertas.
A intenção deste requisito é que as organizações se mantenham atualizadas
quanto a novas vulnerabilidades que poderão interferir no sistema.
Observações:
Os rankings de risco devem ser baseados nas melhores práticas
do setor. Por exemplo, os critérios para o ranking de "Alto" risco
as vulnerabilidades devem incluir uma pontuação de base CVSS
de 4,0 ou mais e/ou um patch oferecido pelo fornecedor
classificado por ele como "crítico" e/ou uma vulnerabilidade que
afere um componente crítico do sistema.
O ranking de vulnerabilidades conforme definido em 6.2.a é
considerado uma das melhores práticas até 30 de junho de 2012
quando passará a ser um requisito.
Ao mesmo tempo que é importante monitorar os anúnicos do revendedor em
busca de notícias de vulnerabilidades e patches relacionados a seus produtos,
também é importante monitorar os grupos comuns de notícias de vulnerabilidades
da indústria e as listas de correspondências em busca de vulnerabilidades e
possíveis contornos que o revendedor poderá ainda não conhecer.
Quando uma organização identifica uma vulnerabilidade que poderá afetar seu
ambiente, o risco que essa vulnerabilidade representa poderá ser avaliado e
classificado. Isto significa que a organização deverá possuir um método para
avliar as vulnerabilidades e atribuir classificações de risco em uma base
consistente. Ao mesmo tempo que cada organização provavelmente terá métodos
diferentes de avaliar uma vulnerabilidade e atribuir uma classificação de risco com
base em CDE exclusivo, será possível criar com base em sistemas de
classificação de risco aceitos pela indústria, como o CVSS. 2.0, NIST SP 800-30,
etc.
Classificar os riscos (por exemplo, como "altos", "médios" ou "baixos") permite que
as organizações identifiquem e encaminhem itens de risco de prioridade alta mais
rapidamente e reduzam a probabilidade de as vulnerabilidades que representarem
maior risco sejam exploradas.
6.3 Desenvolver aplicativos de software (internos e externos,
inclusive acesso de administrador com base na web para
aplicativos) de acordo com o PCI DSS (por exemplo,
autenticação de segurança e login), e com base nas melhores
práticas da indústria, e incorporar segurança de informações
durante o ciclo de vida do desenvolvimento do software. Esses
processos devem incluir o seguinte:
6.3.1 Remoção de contas, IDs de usuário e senhas do
aplicativo antes que ele se torne ativo ou seja lançado aos
clientes
Sem a inclusão de uma proteção durante as fases de definição de requisitos,
design, análise e teste do desenvolvimento de software, as vulnerabilidades de
segurança podem ser introduzidas inadvertida ou maliciosamente no ambiente de
produção.
Contas de aplicativos personalizados, IDs de usuários e senhas devem ser
removidos do código da produção antes de o aplicativo ser ativado ou liberado
para os clientes, pois esses itens podem fornecer informações sobre o
funcionamento do aplicativo. A posse dessas informações pode facilitar o
comprometimento do aplicativo e dos dados relacionados do titular do cartão.
Outubro de 2010
Página 33
Requisito
Orientação
6.3.2 Analisar o código personalizado antes de liberar para
produção ou para os clientes com o objetivo de identificar
qualquer vulnerabilidade potencial de codificação.
As vulnerabilidades de segurança no código personalizado são comumente
exploradas por indivíduos mal-intencionados para obter acesso a uma rede e
comprometer os dados do titular do cartão.
Observação: Esse requisito referente às análises dos códigos
se aplica a todos os códigos personalizados (internos e
voltados para o público), como parte integrante do ciclo de vida
de desenvolvimento do sistema. As análises dos códigos
podem ser realizadas por equipes internas instruídas ou
terceiros. Os aplicativos da Web também estão sujeitos a
controles extras, caso sejam voltados ao público, para
abranger ameaças e vulnerabilidades contínuas após a
implementação, conforme definido no Requisito 6.6 do PCI
DSS.
As revisões do código poderão ser realizadas manualmente ou com o auxílio de
ferramentas de revisão automatizadas. As ferramentas de revisão automatizadas
possuem uma função que revê o código em busca de erros de codificação e
vulnerabilidades. Ao mesmo tempo que a revisão automatizada é útil, em geral
não deverá ser creditada como o único meio de rever códigos. Um indivíduo com
conhecimento e experiência em revisão de códigos deverá estar envolvido no
processo de revisão para identificar problemas de codificação difíceis ou até
impossíveis de serem identificados por uma ferramenta. Atribuir as revisões de
código a alguém que não seja o desenvolvedor do código permitirá que seja
realizada uma revisão independente e objetiva.
6.4 Seguir os procedimentos de controle de alterações para
todas as alterações nos componentes do sistema. Esses
processos devem incluir o seguinte:
Sem controles de alteração adequados, os recursos de segurança podem ser
omitidos sem ou com intenção ou ainda tornados inoperáveis, e podem ocorrer
irregularidades no processamento ou pode ser introduzido um código malintencionado.
6.4.1 Ambientes de desenvolvimento/testes e de produção
separados.
Devido à mutação constante dos ambientes de desenvolvimento e teste, estes
tendem a ser menos seguros do que o ambiente de produção. Sem a separação
adequada entre os ambientes será possível que o ambiente de produção e os
dados do titular do cartão sejam comprometidos por vulnerabilidades em um
ambiente de teste ou desenvolvimento.
6.4.2 Separação dos deveres entre os ambientes de
desenvolvimento/teste e de produção
Reduzir o número de pessoas com acesso ao ambiente de produção e aos dados
do titular do cartão reduz os riscos e ajuda a garantir que o acesso seja limitado
aos indivíduos com necessidade comercial de saber.
A inteção deste requisito é garantir que as funções de desenvolvimento e teste
fiquem separadas das funções de produção. Por exemplo: um desenvolvedor
poderá utilizar uma conta com nível de administrador com privilégios elevados
para uso no ambiente de desenvolvimento, e possuir uma conta em separado com
acesso de nível de usuário ao ambiente de produção.
Em ambientes em que um indivíduo executa diversas funções (por exemplo,
desenvolvimento de aplicativos e implantação de atualizações em sistemas de
produção), as tarefas deverão ser atribuídas de forma que nenhum indivíduo
possua controle total de um processo sem um ponto de verificação independente.
Por exemplo: atribuir responsabilidades de desenvolvimento, autorização e
monitoramento a indivíduos diferentes.
Outubro de 2010
Página 34
Requisito
6.4.3 Os dados de produção (PANs ativos) não são usados
para testes ou desenvolvimento
Orientação
Os controles de segurança normalmente não são tão rígidos no ambiente de
desenvolvimento. O uso de dados de produção dá aos indivíduos malintencionados a oportunidade de ganhar acesso não autorizado aos dados de
produção (dados do titular do cartão).
As bandeiras dos cartões de débito e diversos adquirentes podem fornecer
números de conta adequados para teste caso você precise de PAN realistas para
testar a capacidade de funcionamento do sistema antes de liberar.
6.4.4 Remoção dos dados de teste e contas antes que os
sistemas de produção tornem-se ativos
Dados e contas de teste devem ser removidos do código da produção antes de o
aplicativo ser ativado, pois esses itens podem fornecer informações sobre o
funcionamento do aplicativo. A posse dessas informações pode facilitar o
comprometimento do aplicativo e dos dados relacionados do titular do cartão.
6.4.5 Alterar os procedimentos de controle para
implementação de patches de segurança e modificações de
software. Os procedimentos devem incluir o seguinte:
Sem controles de alteração adequados, os recursos de segurança podem ser
omitidos sem ou com intenção ou ainda tornados inoperáveis, e podem ocorrer
irregularidades no processamento ou pode ser introduzido um código malintencionado. Da mesma forma, uma alteração poderá afetar negativamente o
recurso de segurança de um sistema. Neste caso, a alteração deverá ser desfeita.
6.4.5.1 Documentação de impacto.
O impacto da alteração deve ser documentado de forma que todas as partes
afetadas possam planejar adequadamente as mudanças de processamento.
6.4.5.2 Aprovação documentada de alteração pelas partes
autorizadas.
A aprovação por partes autorizadas indica que a alteração é legítima, e que a
alteração autorizada foi sancionada pela organização.
6.4.5.3 Teste de funcionalidade para verificar se a alteração
não tem impacto adverso sobre a segurança do sistema.
Deverão ser realizados testes rigorosos para verificar se a segurança do ambiente
não se reduz ao ser implantada uma alteração. O teste deverá validar que todos
os controles de segurança existentes permaneçam no lugar, sejam substituídos
por controles igualmente rigorosos ou sejam reforçados após alguma alteração no
ambiente.
Para alterações no código do cliente, o teste também verificará se nenhuma
vulnerabilidade foi introduzida através da alteração.
6.4.5.4 Procedimentos de reversão.
Para cada alteração, deve haver procedimentos de back-out in caso de falha na
alteração, permitindo restaurar de volta para o estado anterior.
Outubro de 2010
Página 35
Requisito
Orientação
6.5 Desenvolver aplicativos baseados nas diretrizes de código
seguro. Prevenir vulnerabilidades de codificação comuns nos
processos de desenvolvimento do software, para incluir o
seguinte:
A camada do aplicativo é de alto risco e pode ser almejada por ameaças internas
e externas. Sem uma segurança adequada, os dados do titular do cartão e outras
informações confidenciais da empresa poderão ser expostos, resultando em
prejuízo à empresa, seus clientes e sua reputação.
Observação: As vulnerabilidades listadas nos itens 6.5.1 a 6.5.9
estavam atualizadas de acordo com as melhores práticas do
setor, quando esta versão do PCI DSS foi publicada. No entanto,
conforme as melhores práticas do setor para o gerenciamento de
vulnerabilidades são atualizadas (por exemplo o Guia OWASP,
SANS CWE Top 25, CERT Secure Coding, etc.), as melhores
práticas atuais precisam ser usadas para estes requisitos.
Como ocorre com todos os requisitos PCI DSS, os requisitos de 6.5.1 a 6.5.5 e de
6.5.7 a 6.5.9 são os controles mínimos que deverão estar no lugar. Esta lista é
composta das práticas de decodificação de segurança mais comuns e aceitas no
momento em que esta versão do PCI DSS foi publicada. Todas as alterações de
práticas de decodificação aceitas pela indústria e as práticas de decodificação
organizacionais deverão igualmente ser atualizadas para que haja
correspondência.
Os exemplos dos recursos de decodificação de segurança fornecidos (SANS,
CERT e OWASP) são fontes de referência sugeridas e deverão ser incluídos
apenas para orientação. Uma organização deverá incorporar as práticas de
decodificação de segurança semelhantes da forma aplicável à tecnologia
particular em seu ambiente.
Outubro de 2010
Página 36
Requisito
Orientação
6.5.1 Falhas na injeção, particularmente na injeção SQL.
Também considere as falhas de injeção de OS Command
Injection, LDAP e XPath, assim como outras falhas.
Valida a entrada para verificar se os dados do usuário não podem modificar o
significado dos comandos e das queries. As falhas de injeção, principalmente de
injeção de SQL, são um método comumente utilizado em aplicativos
comprometidos. A injeção ocorre quando dados fornecidos pelo usuário são
enviados para um intérprete como parte de um comando ou query. Os dados
hostis do transgressor enganam o intérprete para executar comandos não
pretendidos ou para alterar os dados e permitem que o transgressor ataque os
componentes dentro da rede por meio do aplicativo, a fim de iniciar ataques como
buffer overflows, ou para revelar tanto informações confidenciais quando
funcionalidades no aplicativo do servidor. Essa também é uma forma conhecida
de fazer transações fraudulentas em sites habilitados para comércio. As
informações de solicitações devem ser validadas antes de serem enviadas para o
aplicativo – por exemplo, ao verificar todos os caracteres alfabéticos, mistura de
caracteres alfabéticos e numéricos, etc.
6.5.2 Buffer Overflow
Garantir que os aplicativos não fiquem vulneráveis a ataques de buffer overflows.
Os overflows de buffer ocorrem quando um aplicativo não possui uma verificação
de limites adequada em seu espaço de buffer. Para explorar uma vulnerabilidade
de overflow de buffer, um transgressor envia a um aplicativo uma quantidade de
informações superior à que um de seus buffers consegue manejar. Isto pode fazer
com que as informações no buffer sejam empurradas para o espaço da memória
do buffer e o espaço da memória executável. Quando isso ocorre, o transgressor
consegue inserir um código mal-intencionado no final do buffer e empurrar esse
código para o espaço de memória executável ao provocar overflow no buffer. O
código mal-intencionado é então executado e frequentemente permite que o
transgressor acesse remotamente o aplicativo ou o sistema infectado.
6.5.3 Armazenamento criptográfico seguro
Evita falhas criptográficas. Os aplicativos que não utilizam recursos de criptografia
rigorosos da maneira adequada para armazenar dados correm um risco maior de
ficarem comprometidos e de expor os dados do titular do cartão. Caso um
transgressor consiga explorar os processos criptográficos, ele poderá obter
acesso de texto sem criptografia a dados criptografados.
6.5.4 Comunicações inseguras
Criptografe corretamente todas as comunicações autenticadas e confidenciais. Os
aplicativos que não criptografarem adequadamente o tráfego de rede utilizando
criptografia rigorosa correm um risco maior de ficarem comprometidos e de expor
os dados do titular do cartão. Se o transgressor conseguir explorar os processos
criptografados, poderá obter controle de um aplicativo ou até mesmo obter acesso
de texto não criptografado a dados criptografados.
Outubro de 2010
Página 37
Requisito
Orientação
6.5.5 Manuseio incorreto de erros
Não vaze informações por mensagens de erro ou outros meios. Os aplicativos
podem sem querer vazar informações sobre sua configuração, trabalhos internos
ou violar a privacidade por meio de diversos problemas no aplicativo. Os
transgressores usam esse ponto fraco para roubar dados confidenciais ou para
aplicar ataques mais sérios. Além disso, o manuseio incorreto de erros fornece
informações que ajudam um indivíduo mal-intencionado a comprometer o sistema.
Se um indivíduo mal-intencionado puder criar erros que o aplicativo não conseguir
manusear corretamente, eles podem obter informações detalhadas do sistema,
criar interrupções de negação de serviço, causar falhas de segurança ou criar
problemas no servidor. Por exemplo: a mensagem “senha incorreta” diz que o ID
de usuário fornecido está correto e que eles devem concentrar os esforços
somente na senha. Use mensagens de erro mais genéricas, como “os dados não
puderam ser verificados".
6.5.6 Todas as vulnerabilidades "Alto" identificadas no
processo de identificação de vulnerabilidade (conforme definido
no Requisito 6.2 do PCI DSS).
Todas as vulnerabilidades altas observadas pelo Requisito 6.2 que poderiam
afetar o aplicativo deverão ser levadas em consideração durante a fase de
desenvolvimento. Por exemplo: uma vulnerabilidade identificada em uma
biblioteca compartilhada ou no sistema operacional destacado deverá ser avaliada
e encaminhada antes do aplicativo ser liberado para produção.
Observação: Este requisito será considerado uma das
melhores praticas até 30 de junho de 2012 quando passará a
ser um requisito.
Nos aplicativos da web e nas interfaces dos aplicativos
(externos ou internos) serão aplicados os seguintes requisitos
adicionais:
Os aplicativos web, tanto internos quanto externos (públicos), possuem riscos de
segurança exclusivos com base em sua arquitetura e sua relativa facilidade em
apresentar comprometimento.
6.5.7 Scripting de site cruzado (XSS)
Todos os parâmetros devem ser validados antes da inclusão. Ocorrem falhas no
XSS sempre que o aplicativo pegar os dados fornecidos pelo usuário e enviá-los
para um navegador sem primeiro validar ou codificar esse conteúdo. O XSS
permite que os transgressores executem o script no navegador da vítima, que
pode seqüestrar sessões de usuários, desfigurar sites, possivelmente introduzir
worms, etc.
Outubro de 2010
Página 38
Requisito
6.5.8 Controle de acesso inapropriado (como referências
diretas inseguras a objetos, falhas em restringir o acesso a
URLs e diretórios transversais)
Orientação
Não exponha referências de objetos internos aos usuários. Uma referência de
objeto direto ocorre quando o desenvolvedor expõe uma referência a um objeto de
implementação interna, como arquivo, diretório, registro de banco de dados ou
chave, como um URM ou form de parâmetro. Os transgressores podem manipular
essas referências para acessar outros objetos sem autorização.
Força constantemente o controle de acesso na camada de apresentação e na
lógica de negócios para todos os URLs. Muitas vezes um aplicativo só protege os
recursos confidenciais ao evitar a exibição de links ou URLs para usuários não
autorizados. Os transgressores podem usar esse ponto fraco para acessar e
executar operações não autorizadas, acessando diretamente esses URLs.
Proteger contra transversal de diretório. Um transgressor poderá ser capaz de
enumerar e navegar pela estrutura do diretório de um website, obtendo acesso a
informações não autorizadas e descobrindo o funcionamento do site para
exploração futura.
6.5.9 Falsificação de solicitações de site cruzado (CSRF).
6.6 Para aplicativos da Web voltados ao público, abordar novas
ameaças e vulnerabilidades continuamente e assegurar que
esses aplicativos estejam protegidos contra ataques conhecidos
por qualquer um dos métodos a seguir:
Analisar os aplicativos da Web voltados ao público por meio
de ferramentas ou métodos manuais ou automáticos de
avaliação de segurança das vulnerabilidades dos aplicativos,
pelo menos anualmente e após quaisquer alterações
Instalar um firewall para aplicativos da Web diante de
aplicativos da Web voltados ao público
Não responda a credenciais de autorização e tokens enviados automaticamente
pelos navegadores. Um ataque de CSRF força o navegador da vítima logada a
enviar uma solicitação pré-autenticada a um aplicativo da Web vulnerável, que
então força o navegador da vítima a executar uma ação hostil em benefício do
transgressor. O ataque de CSRF pode serão tão poderoso quanto o aplicativo da
Web atacado.
Ataques em aplicativos na Web são comuns e muitas vezes bem-sucedidos, e são
permitidos por práticas de codificação ruins. Este requisito para analisar
aplicativos ou instalar firewalls de aplicativos da Web destina-se a reduzir
enormemente o número de comprometimentos em aplicativos da Web que
resultam em violações nos dados do titular do cartão.
Ferramentas ou métodos de avaliação da segurança de vulnerabilidade
manual ou automatizada e/ou varredura de vulnerabilidades do aplicativo
podem ser usados para satisfazer este requisito.
Firewalls de aplicativo da Web filtram e bloqueiam tráfego não essencial na
camada do aplicativo. Utilizado em conjunto com um firewall baseado em
rede, um firewall de aplicativo da Web configurado corretamente evita ataques
na camada de aplicativos caso estes estejam codificados ou configurados
incorretamente.
Outubro de 2010
Página 39
Orientação para os Requisitos 7, 8 e 9: 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 conhecimento para o
negócio
Para assegurar que os dados críticos possam ser acessados somente por uma equipe autorizada, os sistemas e processos devem estar
implementados para limitar o acesso com base na necessidade de divulgação e de acordo com as responsabilidades da função. A “necessidade
de divulgação” é quando os direitos de acesso são concedidos somente ao menor número possível de dados e privilégios necessários para
realizar um trabalho.
Requisito
Orientação
7.1 Limitar o acesso aos componentes do sistema e aos dados
do titular do cartão somente àquelas pessoas cuja função requer
tal acesso. As limitações de acesso devem incluir o seguinte:
Quanto mais pessoas tiverem acesso aos dados do titular do cartão, mais risco
haverá de que a conta do usuário seja utilizada indevidamente. Limitar o acesso
àquelas pessoas com um forte motivo corporativo para ter esse acesso ajuda sua
organização a evitar o mau uso dos dados do titular do cartão por meio de
inexperiência ou más intenções. Quando os direitos de acesso são concedidos
somente para uma menor quantidade de dados e privilégios necessários para
executar um trabalho, isso se chama "privilégio mínimo" e “necessidade de
divulgação”, e quando os privilégios são atribuídos aos indivíduos com base na
classificação do cargo e na função, isso se chama “controle de acesso baseado
na função” ou RBAC. O reforço do controle de acesso baseado na função não é
limitado a uma camada de aplicativos ou qualquer solução de autorização
específica. Por exemplo, tecnologias incluindo mas não se limitando a serviços de
diretório como Active Directory ou LDAP, Listas de Controle de Acesso (ACLs) e
TACACS são soluções viáveis desde que estejam adequadamente configuradas
para reforçar os princípios de privilégio mínimo e necessidade de divulgação.
7.1.1 Restrição dos direitos de acesso a IDs de usuários
privilegiados ao menor número de privilégios necessários para
desempenhar as responsabilidades da função
7.1.2 A concessão dos privilégios está baseada na
classificação e na atribuição da função da equipe individual
7.1.3 Requisito para aprovação por partes autorizadas
documentada especificando os privilégios exigidos.
7.1.4 Implementação de um sistema de controle de acesso
automático
As organizações devem criar políticas e processos claros para controle de acesso
de dados com base em necessidade de divulgação e usar controle de acesso
baseado na função para definir como e para quem o acesso deverá ser
concedido, inclusive para processos de autorização de gerenciamento adequado.
Outubro de 2010
Página 40
Requisito
Orientação
7.2 Estabeleça um sistema de controle de acesso para os
componentes do sistema com múltiplos usuários que restringe o
acesso com base na necessidade de conhecimento do usuário e
está configurado para "recusar todos", a menos que seja
permitido de forma específica.
Sem um mecanismo para restringir o acesso com base na necessidade de
conhecimento do usuário, este pode sem querer receber acesso aos dados do
titular do cartão. O uso de um sistema ou mecanismo de controle de acesso
automatizado é essencial para gerenciar vários usuários. Esse sistema deve ser
criado segundo as políticas, e os processos de controle de acesso da sua
organização (incluindo “necessidade de acesso” e “controle de acesso baseado na
função”) devem gerenciar o acesso a todos os componentes do sistema e deve ter
uma configuração padrão “recusar todos” para garantir que ninguém receba
acesso até que se crie uma regra dando especificamente tal acesso.
Esse sistema de controle de acesso deve incluir o seguinte:
7.2.1 Abrangência de todos os componentes do sistema
7.2.2 A concessão dos privilégios às pessoas está baseada na
classificação e na atribuição da função
7.2.3 Configuração padrão “recusar todos”
Observação: Alguns sistemas de controle de acesso são
definidos, como padrão, como “permitir todos”, permitindo
portanto o acesso a menos que/até que uma norma seja
redigida para recusá-lo de forma específica.
Outubro de 2010
Página 41
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador
Atribuir uma identificação exclusiva (ID) a cada pessoa com acesso assegura que cada indivíduo seja exclusivamente responsável pelas suas
ações. Quando tal responsabilidade estiver em vigor, as ações desempenhadas nos dados e sistemas críticos serão realizadas por usuários
conhecidos e autorizados, e poderão levar a eles.
Observação: Esses requisitos são aplicáveis a todas as contas, inclusive contas de pontos de venda com capacidades administrativas e todas
as contas usadas para visualizar ou acessar os dados do titular do cartão ou acessar sistemas com dados do titular do cartão. No entanto, os
Requisitos 8.1, 8.2 e 8.5.8 a 8.5.15 não têm por objetivo serem aplicados a contas de usuário em um aplicativo de pagamento de um ponto de
venda que possua acesso somente a um número de cartão por vez para facilitar a transação única (como contas de caixa).
Requisito
Orientação
8.1Atribuir a todos os usuários um ID exclusivo antes de permitir
que eles acessem os componentes do sistema ou os dados do
titular do cartão.
Ao garantir que todos os usuários sejam individualmente identificados, em vez de
usar um ID para vários funcionários, uma organização consegue manter a
responsabilidade individual pelas ações e uma trilha de auditoria eficaz por
funcionário. Isso ajudará a apressar a resolução e a contenção de problemas
quando ocorrer mau uso ou tentativa mal-intencionada.
8.2Além de atribuir um ID exclusivo, um ou mais dos seguintes
métodos foi empregado para autenticar todos os usuários:
Algo que você sabe, como uma senha ou uma passphrase
Algo que você tem, como um dispositivo de token ou um
smart card
Algo que você é, como a biométrica
Esses itens de autenticação, quando usados além dos IDs exclusivos, ajuda a
proteger os IDs exclusivos dos usuários contra o comprometimento (visto que
quem estiver tentando o comprometimento precisa conhecer tanto o ID exclusivo
quanto a senha ou outro item de autenticação).
Certificados digitais são uma opção válida como formulário do tipo de autenticação
"algo que você tem" desde que seja exclusivo.
Outubro de 2010
Página 42
Requisito
Orientação
8.3Incorporar a autenticação por dois fatores para o acesso
remoto (acesso no nível da rede que se origina fora dela) à rede
pelos funcionários, administradores e terceiros. (Por exemplo,
autenticação remota e serviço de dial-in (RADIUS) com tokens;
sistema de controle de acesso ao controlador de acesso ao
terminal (TACACS) com tokens; ou outras tecnologias que
facilitam a autenticação por dois fatores.)
A autenticação de dois fatores exige duas formas de autenticação para acessos
com maior risco, como aqueles originados de fora de sua rede. Para uma
segurança adicional, sua organização também pode considerar o uso da
autenticação de dois fatores ao acessar redes de segurança mais alta a partir de
redes de segurança mais baixa; por exemplo, a partir de computadores desktop
corporativos (segurança mais baixa) para servidores de produção/bancos de
dados com dados do titular do cartão (segurança alta).
Observação: A autenticação de dois fatores exige que dois dos
três métodos de autenticação (consulte o Req. 8.2 com
descrições de métodos de autenticação) sejam usados para
autenticação. Usar um fator duas vezes (e.g., usar duas senhas
separadas) não caracteriza autenticação de dois fatores.
Pretende-se que esse requisito aplique-se aos usuários que possuem acesso
remoto ao trabalho, onde esse acesso remoto pudesse levar ao ambiente de
dados do titular do cartão.
Nesse contexto, o acesso remoto se refere ao acesso em nível de rede originada
de uma rede particular de uma entidade externa, tanto pela Internet como por uma
rede ou sistema "não confiável", como um terceiro ou funcionário acessando a
rede da entidade usando um computador móvel. Acesso interno LAN-a-LAN (por
exemplo, entre dois escritórios por VPN seguro) não é considerado acesso remoto
para os fins deste requisito.
Se o acesso remoto for para a rede de uma entidade que possui segmentação
adequada, como a impossibilidade de acesso a usuários remotos ou de impacto
ao ambiente de dados do titular do cartão, a autenticação de dois fatores para o
acesso remoto àquela rede não será exigida pelo PCI DSS; No entanto, a
autenticação de dois fatores é exigida para qualquer acesso remoto a redes com
acesso ao ambiente de dados do titular do cartão e é recomendável para todo
acesso remoto a redes de entidades.
8.4 Converta todas as senhas em ilegíveis durante a transmissão
e armazenamento em todos os componentes do sistema usando
criptografia robusta.
Muitos dispositivos de rede e aplicativos transmitem o ID do usuário e as senhas
sem criptografia por uma rede e/ou também armazenam as senhas sem
criptografia. Um indivíduo mal-intencionado pode facilmente interceptar o ID de
usuário e a senha sem criptografia ou legível durante a transmissão usando um
“sniffer”, ou então acessar diretamente os IDs do usuário e as senhas não
criptografas em arquivos onde eles são armazenados e usar esses dados
roubados para obter acesso não autorizado. Durante a transmissão, as
credenciais do usuário ou o túnel podem ser criptografados
8.5Garantir um controle adequado da autenticação e da senha
do usuário para usuários que não sejam clientes e
administradores em todos os componentes do sistema, da forma
a seguir:
Como uma das primeiras etapas tomadas por um indivíduo mal-intencionado para
comprometer um sistema é explorar senhas fracas ou inexistentes, é importante
implementar bons processos para identificação de usuários e gestão de
autenticação.
Outubro de 2010
Página 43
Requisito
Orientação
8.5.1Controle o acréscimo, a exclusão e a modificação dos IDs
do usuário, credenciais e outros objetos do responsável pela
identificação.
Para garantir que os usuários adicionados no sistema estejam sejam todos válidos
e reconhecidos, a adição, exclusão e modificação dos IDs do usuário deve ser
gerenciada e controlada por um pequeno grupo com autoridade específica. A
capacidade de gerenciar esses IDs de usuário deve estar limitada somente a esse
pequeno grupo.
8.5.2Verificar a identidade do usuário antes de realizar as
redefinições de senha.
Muitos indivíduos mal-intencionados usam a “engenharia social” – por exemplo,
ligam para o help desk e agem como um usuário legítimo – para trocar a senha,
de forma que possam utilizar um ID de usuário. Pense em usar uma “pergunta
secreta” que só o usuário em si possa responder para ajudar os administradores a
identificarem o usuário antes de redefinir as senhas. As perguntas devem são
protegidas corretamente e não podem ser compartilhadas.
8.5.3 Definir as senhas iniciais para um valor exclusivo para
cada usuário e alterar imediatamente após a primeira
utilização.
Se a mesma senha for usada para todos os novos usuários configurados, um
usuário interno, ex-funcionário ou indivíduo mal-intencionado pode conhecer ou
descobrir facilmente essa senha e usá-la para ter acesso às contas.
8.5.4 Revogar imediatamente o acesso de quaisquer usuários
desligados da empresa.
Se um funcionário sair da empresa e ainda tiver acesso à rede por meio de sua
conta de usuário, pode ocorrer um acesso desnecessário ou mal-intencionado aos
dados do titular do cartão. Esse acesso pode acontecer pelo ex-funcionário ou por
um usuário mal-intencionado que explore a conta antiga e/ou não utilizada. Pense
em implementar um processo com o departamento de RH para notificação
imediata quando um funcionário for desligado da empresa, de forma que a conta
dele possa ser rapidamente desativada.
8.5.5 Remover/desativar as contas dos usuários inativos pelo
menos a cada 90 dias.
A existência de contas inativas permite que um usuário não autorizado explore a
conta não utilizada para possivelmente acessar os dados do titular do cartão.
8.5.6 Ativar as contas usadas pelos fornecedores somente para
a manutenção remota durante o período necessário. Monitorar
as contas de acesso remoto do fornecedor quando estiver em
uso.
Permitir que fornecedores (como os fornecedores do POS) tenham acesso integral
à sua rede caso eles precisem dar suporte ao seu sistema aumenta as chances
de acesso não autorizado, seja de um usuário no ambiente do fornecedor ou de
um indivíduo mal-intencionado que descubra e use esse ponto de entrada externo
sempre pronto para sua rede.
A monitoria do acesso do fornecedor ao ambiente de dados do titular do cartão se
aplica do mesmo modo que para outros usuários, como funcionários da empresa.
Isso inclui monitorar e registrar as atividades conforme exigem os Requisitos 10.1
e 10.2 do PCI DSS e verificar se o uso das contas de fornecedor remoto está de
acordo com a política conforme definido nos Requisitos 12.3.8 e 12.3.9.
8.5.7 Comunicar os processos e políticas de autenticação a
todos os usuários que possuem acesso aos dados do titular do
cartão.
Comunicar os procedimentos de senha a todos os usuários os ajuda a entender e
seguir as políticas e a deixá-los alerta contra indivíduos mal-intencionados que
possam tentar explorar suas senhas para obter acesso aos dados do titular do
cartão (por exemplo, ligando para um funcionário e perguntando sua senha para
que ele possa “resolver um problema”).
Outubro de 2010
Página 44
Requisito
8.5.8 Não use contas, senhas ou outros métodos de
autenticação de grupo, compartilhados ou genéricos .
Orientação
Se vários usuários compartilharem as mesmas credenciais de autenticação (conta
e senha por exemplo), fica impossível atribuir responsabilidade a um usuário ou
fazer um registro eficaz das ações dele, pois uma determinada ação pode ter sido
executada por qualquer pessoa no grupo que compartilhe da conta e da senha.
Esse requisito de IDs exclusivas e senhas complexas é cumprido com frequência
por funções administrativas ao usar, por exemplo, sudo ou SSH para que o
administrador faça o logon inicialmente com seus ID e senha exclusivos e, em
seguida, conecte-se à conta do administrador por meio do sudo ou do SSH.
Normalmente logins de raiz direta são desativados para evitar o uso dessa conta
administrativa compartilhada. Dessa forma, a contabilidade e as trilhas de
auditoria individuais são mantidas. No entanto, mesmo com o uso de ferramentas
como sudo e SSH, os verdadeiros IDs e senhas do administrador também devem
atender aos requisitos do PCI DSS (se tais contras não foram desativadas).
8.5.9 Alterar as senhas do usuário pelo menos a cada 90 dias.
8.5.10Exigir um comprimento mínimo de senha de pelo menos
sete caracteres.
8.5.11 Usar senhas que contenham caracteres alfanuméricos.
8.5.12 Não permitir que ninguém envie uma nova senha que
seja a mesma de uma das quatro últimas senhas que tenha
sido usada.
Senhas fortes são a primeira linha de defesa para uma rede, pois um indivíduo
mal-intencionado muitas vezes primeiro tentará encontrar contas com senhas
fracas ou inexistentes. O indivíduo mal-intencionado terá mais tempo para
localizar essas contas fracas e comprometer uma rede ao estilo de um DI de
usuário válido caso as senhas seja curtas, simples de serem adivinhadas ou
válidas por muito tempo sem alterações. Senhas fortes podem ser forçadas e
mantidas segundo estes requisitos ao ativar os recursos de segurança de senha e
de conta que vêm com o sistema operacional (como o Windows, por exemplo),
redes, bancos de dados e outras plataformas.
8.5.13 Limitar tentativas de acesso repetidas ao bloquear o ID
do usuário após seis tentativas, no máximo.
Sem a implementação de mecanismos de bloqueio de conta, um transgressor
pode tentar continuamente adivinhar uma senha por meio de ferramentas manuais
ou automatizadas (como cracking de senha) até ter sucesso e ganhar acesso à
conta do usuário.
8.5.14Definir a duração do bloqueio para um mínimo de 30
minutos ou até o administrador ativar o ID do usuário.
Se uma conta estiver bloqueada em função de uma pessoa tentar continuamente
adivinhar a senha, os controles para atrasar a reativação dessas contas
bloqueadas evitarão que o indivíduo mal-intencionado continue a tentar adivinhar
a senha (ele terá de parar por pelo menos 30 minutos até a conta ser reativada).
Além disso, se a reativação precisar ser solicitada, a administração ou o help desk
poderão validar que o proprietário da conta é a causa do bloqueio (por causa de
erros de digitação).
8.5.15 Se uma sessão estiver ociosa por mais de 15 minutos,
exigir que o usuário redigite a senha para reativar o terminal.
Quando os usuários se distanciam de uma máquina aberta com acesso a dados
críticos de rede e dados do titular do cartão, essa máquina poderá ser usada por
outras pessoas na ausência do usuário, resultando em acesso não autorizado à
conta e/ou mau uso da conta.
Outubro de 2010
Página 45
Requisito
8.5.16 Autenticar todos os acessos para qualquer banco de
dados que contenha dados do titular do cartão, incluindo
acesso por meio de aplicativos, administradores e todos os
outros usuários.
Restringir acesso direto ou as consultas aos bancos de dados
aos administradores do banco de dados.
Orientação
Sem autenticação do usuário para acesso a bancos de dados e aplicativos, o
potencial para acesso não autorizado ou malicioso aumenta, e esse acesso não
pode ser registrado, pois o usuário não foi autenticado e, assim, não é conhecido
pelo sistema. Além disso, o acesso ao banco de dados só deve ser concedido por
meio de métodos programáticos (por exemplo, por meio de procedimentos
armazenados), e não por acesso direto ao banco de dados por usuários finais
(exceto para DBAs, que podem ter acesso direto ao banco de dados para as
tarefas administrativas).
Outubro de 2010
Página 46
Requisito 9: Restringir o acesso físico aos dados do titular do cartão
Qualquer acesso físico aos dados ou sistemas que armazenam dados do titular do cartão fornecem a oportunidade para as pessoas acessarem
dispositivos ou dados e removerem sistemas ou cópias impressas, e deve ser restrito de forma adequada. Para as finalidades do Requisito 9,
"funcionário" refere-se a funcionários que trabalham em período integral e meio-período, funcionários e equipes temporárias, e prestadores de
serviços e consultores que atuem com presença física no endereço da entidade. Um “visitante” refere-se a um fornecedor, convidado de um
funcionário, equipes de serviço ou qualquer pessoa que precise adentrar as dependências por um breve período, normalmente um dia, no
máximo. "Mídia" refere-se a todas as mídias em papel ou eletrônicas que contêm dados do titular do cartão.
Requisito
Orientação
9.1Usar controles de entrada facilitados e adequados para limitar
e monitorar o acesso físico aos sistemas no ambiente de dados
do titular do cartão.
Sem controles de acesso físico, pessoas não autorizadas podem potencialmente
ganhar acesso ao edifício e às informações confidenciais, e podem alterar as
configurações do sistema, introduzir vulnerabilidades na rede ou destruir ou roubar
equipamentos.
9.1.1 Usar câmeras de vídeo ou outros mecanismos de
controle de acesso para monitorar o acesso físico individual a
áreas confidenciais. Analisar os dados coletados e relacionar
com outras entradas. Armazenar, por pelo menos três meses, a
menos que seja restringido de outra forma pela lei.
Ao investigar violações físicas, esses controles podem ajudar a identificar
indivíduos que acessam fisicamente as áreas que armazenam os dados do titular
do cartão. Exemplos de áreas confidenciais incluem salas de servidor do banco de
dados corporativo, sala de servidor back-end de um local de revenda que
armazene dados do titular do cartão e áreas de armazenamento de grandes
quantidades de dados do titular do cartão,
Observação: “Áreas confidenciais” referem-se a qualquer
central de dados, sala de servidores ou qualquer área que
contenha sistemas que armazenem, processem ou transmitam
dados do titular do cartão. Isso exclui as áreas nas quais há
somente terminais do ponto de venda presentes, como as
áreas dos caixas em uma loja de varejo.
9.1.2 Restringir o acesso físico a pontos de rede acessíveis
publicamente.
Por exemplo, áreas acessíveis a visitantes não devem ter
portas de rede ativadas a não ser que o acesso à rede seja
autorizado explicitamente.
Restringir o acesso aos pontos de rede evita que indivíduos mal-intencionados se
conectem em tomadas de rede prontamente disponíveis que pode lhes dar acesso
aos recursos de rede internos. Pense em desativar as tomadas de rede enquanto
elas não estiverem em uso e reativá-las somente enquanto forem necessárias. Em
áreas públicas, como salas de conferência, crie redes privadas para permitir que
fornecedores e visitantes acessem somente a Internet, e não sua rede interna.
Outubro de 2010
Página 47
Requisito
9.1.3 Restringir o acesso físico a pontos sem fio de acesso,
gateways, dispositivos portáteis, hardwares de
comunicação/rede e linhas de telecomunicação.
Orientação
Sem segurança no acesso a componentes e dispositivos wireless, indivíduos malintencionados podem usar os dispositivos wireless da sua empresa que não
estejam sendo utilizados para acessar os recursos de rede ou até para conectar
seus próprios dispositivos à rede wireless para obter acesso não autorizado. Além
disso, fazer a segurança dos materiais de comunicação e rede evita que usuários
mal-intencionados interceptem o trafego da rede ou conectem-se fisicamente seus
próprios dispositivos em seus recursos de rede com fio.
Pense em colocar pontos de acesso wireless, gateways e material de
comunicação/redes em áreas de armazenamento seguro, como dentro de
armários trancados ou salas de servidores. Para redes wireless, assegure-se de
que a criptografia robusta está ativada. Ative o bloqueio automático de dispositivo
em dispositivos portáteis wireless após um período longo parado e defina um uma
senha nos dispositivos quando eles forem iniciados.
9.2 Desenvolver procedimentos para diferenciar facilmente os
funcionários dos visitantes, principalmente nas áreas onde os
dados do titular do cartão podem ser acessados.
Sem sistemas de crachás e controles de porta, usuários não autorizados e malintencionados podem facilmente obter acesso às instalações para roubar,
desativar, interromper ou destruir sistemas críticos e dados do titular do cartão.
Para o controle ideal, pense em implementar um sistema de acesso por crachá ou
carrão dentro e fora das áreas de trabalho que contenham dados do titular do
cartão.
Identificar visitantes autorizados para que sejam facilmente distinguidos dos
funcionários do local evita que os visitantes não autorizados acessem áreas
contendo dados do titular do cartão.
9.3 Certificar-se de que todos os visitantes são identificados da
seguinte forma:
9.3.1 Autorizados antes de adentrar as áreas onde os dados do
titular do cartão são processados ou mantidos.
9.3.2 Recebem um token físico (por exemplo, um crachá ou
dispositivo de acesso) que expira e que identifica os visitantes
como não sendo funcionários.
O controle de visitantes é importante para reduzir a possibilidade de pessoas não
autorizadas e mal-intencionadas obterem acesso a suas instalações (e
possivelmente aos dados do titular do cartão).
Os controles de visitantes são importantes para garantir que eles só entrem em
áreas onde são autorizados e que sejam identificados como visitantes, de forma
que os funcionários possam monitorar suas atividades e que o acesso esteja
restrito a somente a duração da visita em si.
9.3.3 É solicitado que os visitantes apresentem o token físico
antes de sair das dependências ou na data do vencimento
Outubro de 2010
Página 48
Requisito
Orientação
9.4 Usar um registro de visitantes para manter um
monitoramento físico da auditoria da atividade do visitante.
Documente no registro o nome do visitante, a empresa
representada e o funcionário que autoriza o acesso físico.
Armazene esse registro por pelo menos três meses, a menos
que seja restringido de outra forma pela lei.
Um log de visitantes, documentando as informações mínimas sobre eles, é de
manutenção fácil e barata e, durante uma possível violação de dados, ajuda a
identificar acesso físico a um edifício ou a uma sala e um possível acesso aos
dados do titular do cartão. Pense em implementar logs na entrada às instalações
e, especialmente, em zonas onde estejam presentes os dados do titular do cartão.
9.5 Armazene back-ups de mídia em um local seguro,
preferencialmente em outras instalações, como um lugar
alternativo de back-up ou uma instalação comercial de
armazenamento. Analisar a segurança do local pelo menos uma
vez por ano.
Se armazenados em um local não protegido, os backups que contêm dados do
titular do cartão podem ser facilmente perdidos, roubados ou copiados com más
intenções. Para armazenamento protegido, pense em contratar uma empresa de
armazenamento de dados comerciais OU, para empresas menores, usar um cofre
em um banco.
9.6 Proteja toda a mídia fisicamente.
Os dados do titular do cartão estarão suscetíveis a visualização, cópia ou
digitalização não autorizada caso estejam desprotegidos enquanto estiverem em
mídia portátil, forem impressos ou deixados na mesa de alguém.
9.7 Manter o controle rigoroso quanto à distribuição interna ou
externa de qualquer tipo de mídia, incluindo o seguinte:
Procedimentos e processos para proteger os dados do titular do cartão em mídias
distribuídas a usuários internos e/ou externos. Sem tais procedimentos, os dados
poderão ser perdidos ou roubados e usados para fins fraudulentos.
9.7.1 Classificar a mídia para que a confidencialidade dos
dados possa ser determinada.
É importante que a mídia seja identificada para que seu status de classificação
possa ser discernível. A mídia não identificada como confidencial pode não ser
protegida adequadamente ou ser roubada.
9.7.2 Enviar a mídia via mensageiro seguro ou outro método de
entrega que pode ser monitorado com precisão.
A mídia pode ser perdida ou roubada se for enviada por um método não
rastreável, como remessa postal. Use os serviços de um mensageiro seguro para
entregar mídias que contenham dados do titular do cartão, de forma que você
possa usar os sistemas de rastreamento para manter inventário e localização dos
envios.
9.8 Certificar-se de que a gerência aprova quaisquer e todas as
mídias contendo dados do titular do cartão que são movidas de
uma área segura (principalmente quando as mídias forem
distribuídas às pessoas).
Os dados do titular do cartão que saem de áreas seguras sem um processo
aprovado pela gerência podem levar a dados perdidos ou roubados. Sem um
processo firme, os locais de mídia não são rastreados e não existe um processo
para onde os dados vão ou a forma como eles são protegidos.
9.9 Manter um controle rigoroso sobre o armazenamento e a
acessibilidade das mídias que contêm dados do titular do cartão.
Sem métodos cuidadosos de inventário e controles de armazenamento, mídias
roubadas ou ausentes podem passar despercebidas por tempo indefinido.
9.9.1 Manter adequadamente os registros do inventário de
todas as mídias e realizar inventários das mídias pelo menos
uma vez por ano.
Se a mídia não passar por inventário, mídias roubadas ou perdidas podem passar
despercebidas por bastante tempo.
Outubro de 2010
Página 49
Requisito
Orientação
9.10 Destruir as mídias que contêm dados do titular do cartão
quando eles não forem mais necessários por motivos de
negócios ou legais, conforme se segue:
Se as etapas não forem seguidas par destruir as informações contidas em discos
rígidos, drives portáteis, CD/DVDs ou papéis antes do descarte, indivíduos malintencionados poder estar aptos a recuperar as informações da mídia descartada,
levando ao comprometimento dos dados. Por exemplo: indivíduos malintencionados podem usar uma técnica conhecida como “dumpster diving”, na
qual eles pesquisam em lixeiras e usam as informações encontradas para iniciar
um ataque.
9.10.1 Triturar, incinerar ou amassar materiais impressos para
que os dados do titular do cartão não possam ser recuperados.
9.10.2Tornar os dados do titular do cartão nas mídias
eletrônicas irrecuperáveis para que esses dados não possam
ser reconstituídos.
Exemplos de métodos para destruir mídias eletrônicas incluem limpeza segura,
desmagnetização ou destruição física (como esmagar ou triturar os discos
rígidos).
Outubro de 2010
Página 50
Orientação para os Requisitos 10 e 11: 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
Mecanismos de registro e a capacidade de monitorar as atividades dos usuários são fundamentais na prevenção, detecção ou minimização do
impacto do comprometimento dos dados. A presença de registros em todos os ambientes permite o monitoramento, o alerta e a análise completa
quando algo dá errado. Determinar a causa de um comprometimento é muito difícil, se não impossível, sem registros das atividades do sistema.
Requisito
Orientação
10.1 Definir um processo para vincular todos os acessos aos
componentes do sistema (principalmente o acesso realizado com
privilégios administrativos como raiz) para cada usuário
individual.
É essencial ter um processo ou sistema que vincule o acesso do usuário aos
componentes do sistema acessados e, mais particularmente, àqueles usuários
com privilégios administrativos. Esse sistema gera logs de auditoria e oferece a
capacidade de rastrear as atividades suspeitas de um usuário específico. Equipes
forenses pós-incidente dependem muito desses logs para iniciar a investigação.
Implementar trilhas de auditoria automatizadas para todos os
componentes do sistema para recuperar os seguintes eventos:
Gerar trilhas de auditoria de atividades suspeitas alerta o administrador do
sistema, envia dados a outros mecanismos de monitoramento (como sistemas de
detecção de intrusão) e fornece uma trilha do histórico para acompanhamento
pós-acidente. Registrar os seguintes eventos permite que uma empresa
identifique e rastreie atividades potencialmente mal-intencionadas.
10.2.1 Todos os acessos individuais aos dados do titular do
cartão
Indivíduos mal-intencionados poderiam tomar conhecimento de uma conta de
usuário com acesso aos sistemas no CDE ou poderiam criar uma conta nova, não
autorizada, para acessar os dados do titular do cartão. Um registro de todos os
acessos individuais para os dados do titular do cartão pode identificar quais contas
podem ter sido comprometidas ou usadas inadequadamente.
10.2.2 Todas as ações desempenhadas por qualquer pessoa
com privilégios raiz ou administrativos
Contas com privilégios maiores, como "administrador" ou "raiz", têm o potencial
para impactar fortemente a segurança ou a funcionalidade operacional de um
sistema. Sem o registro das atividades executadas, uma empresa não é capaz de
rastrear qualquer problema resultante de algum erro administrativo ou uso
inadequado de privilégios de volta à ação específica e ao indivíduo.
10.2.3 Acesso a todas as trilhas de auditoria
Usuários mal-intencionados tentam frequentemente alterar os registros de
auditoria para ocultar suas ações e um registro de acesso permite que uma
empresa rastreia quaisquer inconsistências ou potenciais adulterações dos
registros para uma conta individual.
10.2.4 Tentativas inválidas de acesso lógico
Indivíduos mal-intencionados na rede muitas vezes executam várias tentativas de
acesso nos sistemas alvejados. Várias tentativas inválidas de login podem ser um
indicador de tentativas de um usuário não autorizado "forçar" ou adivinhar uma
senha.
Outubro de 2010
Página 51
Requisito
Orientação
10.2.5 Uso de mecanismos de identificação e autenticação
Sem saber quem estava registrado no momento de um incidente, é impossível
identificar as contas que podem ter sido usadas. Além disso, usuários malintencionados tentam manipular os controles de autenticação com o objetivo de
contorná-los ou imitar uma conta válida. Atividades incluindo, mas não limitadas a,
escalação de privilégio ou alterações nas permissões de acesso podem indicar
uso não autorizado de mecanismos de autenticação.
10.2.6 Inicialização dos registros de auditoria
Desativar os registros de auditoria antes de realizar atividades ilícitas é uma meta
comum a usuários mal-intencionados que desejam evitar ser detectados. A
inicialização dos registros de auditoria podem indicar que a função de registro foi
desativada.
10.2.7 Criação e exclusão de objetos do nível do sistema
Softwares mal-intencionados, como malwares, frequentemente criam ou
substituem objetos no nível do sistema no sistema de destino para controlar uma
função ou operação nesse sistema.
Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS e
PA-DSS para obter definições de "objetos no nível do sistema".
10.3 Registrar pelo menos as seguintes entradas das trilhas de
auditoria para todos os componentes do sistema para cada
evento:
Ao registrar esses detalhes para os eventos auditáveis em 10.2, um possível
comprometimento poderá ser rapidamente identificado, e com detalhes suficientes
para saber quem, o que, onde, quando e como.
10.3.1 Identificação do usuário
10.3.2 Tipo de evento
10.3.3 Data e horário
10.3.4 Indicação de sucesso ou falha
10.3.5 Origem do evento
10.3.6 A identidade ou o nome dos dados afetados,
componentes do sistema ou recurso
Outubro de 2010
Página 52
Requisito
Orientação
10.4 Usando tecnologia de sincronização de tempo, sincronize
todos os relógios e horários críticos do sistema e assegure-se de
que os seguintes itens sejam implementados para adquirir,
distribuir e armazenar horários.
A tecnologia para sincronização do horário é usada para sincronizar os relógios.
Quando implementada corretamente, essa tecnologia pode sincronizar relógios
em um grande quantidade de sistemas com uma fração de segundo de um para
outro. Alguns problemas que podem ocorrer quando os relógios não são
sincronizados adequadamente incluem, mas não se limitam a tornar difícil (se não
impossível) comparar arquivos de registro de diferentes sistemas, estabelecer
uma sequência exata de eventos (cruciais para análise forense no caso de uma
violação) e evitar que protocolos criptográficos (como SSH) dependentes de
horário absoluto funcionem adequadamente. Para equipes de forenses pósincidente, a precisão e a consistência do horário ao longo de todos os sistemas e
a hora de cada atividade são essenciais para determinar a forma como os
sistemas foram comprometidos.
Observação: Um exemplo de tecnologia de sincronização de
tempo é o Network Time Protocol (NTP).
10.4.1 Sistemas críticos têm o horário correto e consistente
10.4.2 Os dados de horário são protegidos
10.4.3 As definições de horário são recebidas de fontes de
horário aceitas pelo setor
Para garantir um horário consistente, deve haver idealmente somente alguns
servidores de horário internos (centrais) dentro de uma entidade. Esses servidores
recebem o UTC (Tempo Universal Coordenado) diretamente de servidores de
horário externos, conhecidos e confiáveis, por meio de rádio especial, satélites de
GPS ou outra fonte de rede externa e se emparelham para garantir que
mantenham o horário preciso. Outros sistemas recebem, então, o horário desses
servidores.
Se um indivíduo mal-intencionado tiver entrado na rede, ele muitas vezes tentará
mudará os carimbos de data e hora de suas ações dentro dos logs de auditoria
para evitar a detecção da atividade. Um indivíduo mal intencionado também pode
tentar alterar diretamente o relógio de um componente do sistema para ocultar sua
presença - por exemplo, alterando o relógio do sistema para um horário mais
cedo. Por estes motivos, é importante que o horário seja preciso em todos os
sistemas e que os dados de horário sejam protegidos contra acessos e alterações
não autorizados. Dados de horário incluem os parâmetros e os métodos usados
para definir o relógio de cada sistema.
Mais informações sobre NTP podem ser encontradas em www.ntp.org, inclusive
informações sobre horário, padrões de horário e servidores.
10.5 Proteger as trilhas de auditoria para que não possam ser
alteradas.
Muitas vezes um indivíduo mal-intencionado que entra em uma rede tenta editar
os logs de auditoria para ocultar suas atividades. Sem proteção adequada dos
logs de auditoria, sua conclusão, precisão e integridade não poderão ser
garantidas, e os logs de auditoria poderão ser inutilizados como ferramenta de
investigação após um comprometimento.
Outubro de 2010
Página 53
Requisito
10.5.1 Limitar a exibição de trilhas de auditoria às pessoas que
têm uma necessidade relacionada à função.
10.5.2 Proteger os arquivos de trilha de auditoria de
modificações não autorizadas.
10.5.3 Fazer imediatamente o back-up dos arquivos de trilha de
auditoria em um servidor de registros centralizado ou mídias
que sejam difíceis de alterar.
Orientação
Uma proteção adequada dos logs de auditoria inclui forte controle de acesso
(limitar o acesso aos logs baseado somente na “necessidade de divulgação”) e
uso da segregação interna (para deixar os logs mais difíceis de serem
encontrados e modificados). Ao gravar os logs de tecnologias que usam recursos
externos, como wireless, firewalls, DNS e servidores de e-mail, o risco de esses
logs serem perdidos ou alterados é diminuído, pois eles estão mais seguros
dentro da rede interna.
10.5.4 Documentar registros quanto às tecnologias externas
em um servidor de registros na LAN interna.
10.5.5 Usar softwares de monitoramento da integridade dos
arquivos ou de detecção de alterações nos registros para
assegurar que os dados de registro existentes não possam ser
alterados sem gerar alertas (embora os novos dados que
estejam sendo adicionados não gerem um alerta).
10.6 Analisar os registros de todos os componentes do sistema
pelo menos diariamente. As análises dos registros incluem
aqueles servidores que desempenham funções de segurança
como sistema de detecção de invasões (IDS) e servidores de
protocolo de autenticação, autorização e inventário (AAA) (por
exemplo, RADIUS).
Os sistemas de monitoramento da integridade do arquivo verificam as alterações
nos arquivos críticos e notificam quando essas alterações são observadas. Para
fins de monitoramento da integridade do arquivo, uma entidade normalmente
monitora os arquivos que não mudam regularmente, mas que, quando alterados,
indicam um possível comprometimento. Para arquivos de registro (que não
mudam com frequência), o que deve ser monitorado é, por exemplo, quando um
arquivo de log é excluído, cresce rapidamente ou diminui significativamente, e
quaisquer outras indicações de que um indivíduo mal-intencionado mexeu
indevidamente no arquivo de log. Existem ferramentas de prateleira e de código
aberto disponíveis para monitoramento da integridade do arquivo.
Várias violações ocorrem durante dias ou meses antes de serem detectadas. A
verificação diária dos logs minimiza a quantidade de tempo e exposição de uma
violação em potencial. O processo de análise do log não precisa ser manual.
Especialmente para as entidades com um grande número de servidores, pense
em usar ferramentas de coleta, análise e alerta de log.
Observação: As ferramentas de coleta, análise e alerta dos
registros podem ser usadas para estar em conformidade com o
Requisito 10.6
10.7 Manter um histórico da trilha de auditoria por pelo menos
um ano, com um mínimo de três meses imediatamente
disponível para análise (por exemplo, on-line, arquivado ou
recuperável a partir do back-up).
Guardar os logs por pelo menos um ano leva em conta o fato de muitas vezes se
levar um tempo até notar que ocorreu ou está ocorrendo um comprometimento, e
permite que os investigadores tenham um histórico de log suficiente para
determinar melhor a quantidade de tempo de uma potencial violação e os
possíveis sistemas afetados. Ao ter três meses de logs imediatamente
disponíveis, uma entidade pode rapidamente identificar e minimizar o impacto da
violação de dados. O armazenamento de tarjas de backup fora do local pode
resultar em cronogramas mais longos para restaurar dados, executar análises e
identificar sistemas ou dados afetados.
Outubro de 2010
Página 54
Requisito 11: Testar regularmente os sistemas e processos de segurança
As vulnerabilidades estão sendo continuamente descobertas por indivíduos mal-intencionados e pesquisadores, e são apresentadas por novos
softwares. Os componentes do sistema, processos e softwares personalizados devem ser testados com frequência para assegurar que os
controles de segurança continuem refletindo um ambiente em transformação.
Requisito
Orientação
11.1 Teste para a presença de pontos de
acesso sem fio e detectar pontos de acesso
sem fio não autorizados trimestralmente.
A implementação e/ou exploração da tecnologia wireless dentro de uma rede é um dos caminhos
mais comuns para usuários mal-intencionados obterem acesso à rede e aos dados do titular do
cartão. Se um dispositivo wireless ou uma rede forem instalados sem o conhecimento da empresa,
ele pode permitir que um transgressor entre na rede de forma fácil e invisível.
Observação: Métodos que podem ser usados
no processo incluem mas não se limitam a
varreduras de rede sem fio, inspeções
físicas/lógicas de componentes e de
infraestrutura do sistema, controle de acesso
à rede (NAC) ou IDS/IPS sem fio.
Qualquer método usado deve ser suficiente
para detectar e identificar qualquer dispositivo
não autorizado.
Dispositivos sem fio não autorizados devem ser ocultados ou anexados a um computador ou outro
componente do sistema, ou ser anexados diretamente a uma porta ou dispositivo da rede, como um
switch ou roteador. Qualquer desses dispositivos não autorizados podem resultar em um ponto não
autorizado de acesso ao ambiente.
Em função da facilidade com que o ponto de acesso wireless pode ser conectado a uma rede, da
dificuldade em detectar sua presença e do risco cada vez maior apresentado por dispositivos wireless
não autorizados, esses processos devem ser executados até quando existir uma política proibindo o
uso da tecnologia wireless.
O tamanho e a complexidade de um ambiente privado determinarão as ferramentas e os processos
adequados a serem usados para fornecer garantia suficiente de que um ponto de acesso sem fio
intruso não tenha sido instalado no ambiente.
Por exemplo: No caso de um único quiosque de revenda autônomo em um shopping, onde todos os
componentes de comunicação estão contidos em estojos anti-adulteração e indicadores de
adulteração, executando inspeções físicas detalhadas no próprio quiosque pode ser suficiente para
fornecer garantias de nenhum ponto de acesso sem fio intruso foi anexado ou instalado. No entanto,
em um ambiente com vários nós (como em uma grande loja de revenda, um call center, sala de
servidor ou centro de dados), torna-se mais difícil executar uma inspeção física detalhada devido ao
número de componentes do sistema e de pontos de rede onde um dispositivo de acesso sem fio
intruso poderia ser instalado ou ocultado. Nesse caso, vários métodos podem ser combinados para
atender ao requisito, como executar inspeções físicas no sistema em conjunto com os resultados de
um analisador sem fio.
Soluções de controle de acesso de rede (NAC) podem executar o gerenciamento de autenticação e
configuração do dispositivo para evitar que sistemas não autorizados conectem-se à rede, ou que
dispositivos não autorizados conectem-se a sistemas autorizados na rede.
Uma organização deve ter, como parte de seu plano de resposta a incidentes, procedimentos
documentados a serem seguidos no caso de ser detectado um ponto de acesso wireless não
autorizado. Um IDS/IPS wireless deve ser configurado para gerar automaticamente um alerta, mas o
plano também deve documentar procedimentos de resposta caso um dispositivo não autorizado seja
Outubro de 2010
Página 55
Requisito
Orientação
detectado durante uma varredura wireless manual.
11.2 Executar varreduras quanto às
vulnerabilidades das redes internas e
externas pelo menos trimestralmente e após
qualquer mudança significativa na rede (como
instalações de novos componentes do
sistema, mudanças na topologia da rede,
modificações das normas do firewall,
upgrades de produtos).
Uma varredura de vulnerabilidade é uma ferramenta automatizada executada em dispositivos de rede
interna e externa e servidores, feita para expor possíveis vulnerabilidades e identificar portas em
redes que podem ser encontradas e exploradas por indivíduos mal-intencionados. Quando esses
pontos fracos são identificados, a entidade os corrige e repete a verificação para chegar se as
vulnerabilidades foram mesmo corrigidas.
Observação: Não será necessário que quatro
varreduras trimestrais aprovadas sejam
concluídas quanto à conformidade inicial do
PCI DSS se o avaliador verificar que 1) o
resultado da varredura mais recente foi uma
varredura aprovada, 2) a entidade contar com
políticas e procedimentos documentados que
requerem a sequência de varreduras
trimestrais e 3) as vulnerabilidades
observadas nos resultados da varredura
tenham sido corrigidas conforme mostrado em
uma nova varredura. Nos anos seguintes
após a análise inicial do PCI DSS, quatro
varreduras trimestrais aprovadas devem ter
ocorrido.
No momento da avaliação inicial do PCI DSS pela entidade, é possível que quatro varreduras
trimestrais ainda não tenham sido realizadas. Se o resultado da verificação mais recente atingir os
critérios para aprovação e houver políticas e procedimentos para varreduras trimestrais futuras, o
objetivo desse requisito estará atingido. Caso essas condições sejam atendidas, não é necessário
postergar uma avaliação “no local” para este requisito em função da falta de quatro varreduras.
Outubro de 2010
Página 56
Requisito
11.2.1 Realizar varreduras por
vulnerabilidade interna trimestralmente.
Orientação
Um processo estabelecido para identificar vulnerabilidades em sistemas internos no CDE exigem que
as varreduras de vulnerabilidade sejam conduzidas trimestralmente. Identificar e abordar as
vulnerabilidades em tempo hábil reduz as chances de exploração de uma vulnerabilidade e o
comprometimento potencial de um componente do sistema ou de dados do titular do cartão.
As vulnerabilidades que representam o maior risco ao ambiente (por exemplo, ranqueadas como
"Alto" pelo Requisito 6.2) deve ser resolvida com a maior prioridade.
Como redes internas podem ser constantemente alteradas durante o ano, é possível que uma
entidade possa não ter limpado consistentemente as varreduras de vulnerabilidades internas. A
intenção é que a entidade tenha um programa robusto de gerenciamento de vulnerabilidade instalado
para resolver vulnerabilidades observadas em um período de tempo razoável. No mínimo as
vulnerabilidades "Alto" devem ser abordadas rapidamente.
Varreduras de vulnerabilidade internas podem ser realizadas por profissionais internos, qualificados
que sejam razoavelmente independentes dos componentes do sistema sendo varridos (por exemplo,
um administrador de firewall não deve ser responsável pela varredura do firewall) ou a entidade pode
optar por fazer as varreduras de vulnerabilidade internas por um Fornecedor de Varreduras Aprovado
(ASV) do PCI SSC, QSA ou outra firma especializada em varreduras de vulnerabilidade.
11.2.2 As varreduras trimestrais quanto às
vulnerabilidades externas devem ser
realizadas por um Fornecedor de
Varreduras Aprovado (ASV) qualificado pelo
Conselho de Segurança de Dados do Setor
de Cartões de Pagamento (PCI SSC).
Como redes externas têm um risco maior de comprometimento, a varredura de vulnerabilidade
externa trimestral deve ser realizada por um Fornecedor de Varreduras Aprovado (ASV) do PCI SSC.
Exige-se que os ASVs sigam um conjunto de critérios de varredura e relatórios definidos pelo PCI
SSC nos Procedimentos de varredura de segurança.
Observação: As varreduras trimestrais
quanto às vulnerabilidades externas devem
ser realizadas por um Fornecedor de
Varreduras Aprovado (ASV) qualificado pelo
Conselho de Segurança de Dados do Setor
de Cartões de Pagamento (PCI SSC). As
varreduras realizadas após as alterações na
rede devem ser desempenhadas pela
equipe interna da empresa.
11.2.3 Realize varreduras internas e
externas após qualquer mudança
significativa.
Observação: As varreduras realizadas
após as alterações devem ser
desempenhadas pela equipe interna da
empresa.
Varrer um ambiente depois de qualquer alteração significativa ter sido feita assegura que todas as
alterações foram completamente adequadas para que a segurança do ambiente não tenha sido
comprometida como resultado da alteração. Pode não ser necessário varrer o ambiente completo
após uma alteração. No entanto, todos os componentes afetados pela alteração precisaram ser
varridos.
Outubro de 2010
Página 57
Requisito
Orientação
11.3 Realizar testes de penetração externos e
internos pelo menos uma vez por ano e após
qualquer upgrade ou modificação significativa
na infra-estrutura ou nos aplicativos (como um
upgrade no sistema operacional, uma subrede adicionada ao ambiente ou um servidor
da Web adicionado ao ambiente). Esses
testes de penetração devem incluir o
seguinte:
A intenção de um teste de penetração é estimular uma situação de ataque real com o objetivo de
identificar até onde um transgressor conseguiria penetrar em um ambiente. Isso permite que a
entidade tenha mais compreensão sobre sua potencial exposição e desenvolva uma estratégia para
se defender de ataques.
11.3.1 Testes de penetração na camada da
rede
11.3.2 Testes de penetração na camada do
aplicativo.
Um teste de penetração difere de uma varredura de vulnerabilidade, uma vez que o teste de
penetração é um processo ativo que pode incluir a exploração de vulnerabilidades identificadas.
Normalmente, executar uma varredura de vulnerabilidade é um dos primeiros passos que um
testador de penetração realizará para formar uma estratégia de ataque, mesmo que não seja o único
passo. Mesmo que uma varredura de vulnerabilidade não detecte nenhuma vulnerabilidade
conhecida, o testador de penetração irá normalmente tomar conhecimento suficiente sobre o sistema
para identificar possíveis lacunas de segurança.
O teste de penetração é geralmente um processo altamente manual. Enquanto algumas ferramentas
automatizadas podem ser usadas, o testador deve utilizar seu conhecimento de sistemas para
penetrar em um ambiente. Normalmente o testador irá conectar diversos tipos de explorações com o
objetivo de ultrapassar camadas de defesas. Por exemplo, se o testador encontrar meios de obter
acesso a um servidor de aplicativo, em seguida ele usará o servidor comprometido como um ponto
de preparação para um novo ataque baseado nos recursos a que o servidor tem acesso. Dessa
forma, o testador é capaz de simular os métodos utilizados por um transgressor para identificar
qualquer área de fraquezas potenciais no ambiente que precisa ser abordado.
Outubro de 2010
Página 58
Requisito
Orientação
11.4 Usar sistemas de detecção de invasão
e/ou sistemas de prevenção contra invasão
para monitorar todo o tráfego no ambiente de
dados do titular do cartão e alertar as equipes
sobre comprometimentos suspeitos.
A detecção de intrusos e/ou prevenção de sistemas (IDS/IPS) comparam o tráfego que entra na rede
com “assinaturas” conhecidas e/ou milhares de tipos de comprometimento (ferramentas de hacker,
Trojans e outros tipos de malware) e envia alertas e/ou interrompe a tentativa enquanto ela está
acontecendo. Sem uma abordagem proativa a uma detecção de atividade não autorizada por meio
dessas ferramentas, os ataques (ou mau uso) de recursos de computador podem passar
despercebidos em tempo real. Os alertas de segurança gerados por essas ferramentas devem ser
monitorados, de forma que as tentativas de intrusão possam ser interrompidas.
Manter todos os mecanismos de detecção e
prevenção contra invasões, diretrizes e
assinaturas atualizados.
Dispositivos IDS/IPS devem ser implementados de maneira a monitorar o tráfego de entrada e saída
no perímetro do CDE, além dos pontos críticos no CDE. Os pontos críticos no CDE podem incluir
servidores de bancos de dados que armazenam dados dos titulares dos cartões, locais de
armazenamento de chaves de criptografia, redes de processamento ou outros componentes
delicados do sistema, de acordo com o que for determinado pelo ambiente de uma entidade e
documentado em sua avaliação de riscos.
Enquanto vários dispositivos IDS/IPS são capazes de monitorar diversos pontos do CDE a partir de
um único dispositivoe, é importante lembrar da exposição que pode ocorrer caso esse único
dispositivo falhe. Portanto, é importante incorporar a redundância adequada na infraestrutura
IDS/IPS.
Existem milhares de tipos de comprometimento, e vários outros são descobertos diariamente.
Assinaturas e mecanismos de varredura antigos em dispositivos IDS/IPS não oferecem a capacidade
de identificar novas vulnerabilidades que podem levar a uma violação não detectada. Os
fornecedores desses produtos oferecem atualizações frequentes, inclusive diárias, que devem ser
avaliadas e aplicadas regularmente.
Outubro de 2010
Página 59
Requisito
Orientação
11.5 Implementar softwares de
monitoramento da integridade dos arquivos
para alertar as equipes quanto à modificação
não autorizada de arquivos críticos do
sistema, arquivos de configuração ou arquivos
de conteúdo; e configurar o software para
realizar comparações de arquivos críticos pelo
menos semanalmente.
Os sistemas de monitoramento da integridade do arquivo (FIM) verificam as alterações nos arquivos
críticos e notificam quando essas alterações são detectadas. Existem ferramentas de prateleira e de
código aberto disponíveis para monitoramento da integridade do arquivo. Se não implementadas
corretamente e se o resultado do FIM não for monitorado, um indivíduo mal-intencionado pode alterar
o conteúdo do arquivo de configuração, os programas do sistema operacional ou os executáveis do
aplicativo. Essas alterações não autorizadas, se não detectadas, podem tornar os controles de
segurança ineficazes e/ou resultar no roubo dos dados do titular do cartão sem impacto perceptível
no processamento normal.
Observação: Para fins de monitoramento da
integridade dos arquivos, os arquivos críticos
normalmente são aqueles que não são
alterados com frequência, mas sua
modificação poderia indicar um
comprometimento do sistema ou um risco de
comprometimento. Normalmente, os produtos
de monitoramento da integridade dos arquivos
vêm pré-configurados com arquivos críticos
para o sistema operacional relacionado.
Outros arquivos críticos, como aqueles para
os aplicativos personalizados, devem ser
avaliados e definidos pela entidade (ou seja, o
comerciante ou prestador de serviços).
Outubro de 2010
Página 60
Orientação para o Requisito 12: Manter uma Política de Segurança de Informações
Requisito 12: Manter uma política que aborde a segurança das informações para todas as equipes.
Uma política de segurança sólida determina o tom da segurança para toda a empresa e informa aos funcionários o que é esperado deles. Todos
os funcionários devem estar cientes da confidencialidade dos dados e de suas responsabilidades para protegê-los. Para as finalidades do
Requisito 12, "funcionário" refere-se a funcionários que trabalham em período integral e meio-período, funcionários e equipes temporárias, e
prestadores de serviços e consultores que "residem" no endereço da entidade ou têm acesso ao ambiente de dados do titular do cartão.
Requisito
Orientação
12.1 Definir, publicar, manter e disseminar uma política de
segurança que realize o seguinte:
A política de segurança de informações de uma empresa cria um guia para
implementar as medidas de segurança para proteger seus ativos mais valiosos.
Uma política de segurança sólida determina o tom da segurança para toda a
empresa e informa aos funcionários o que é esperado deles. Todos os
funcionários devem estar cientes da confidencialidade dos dados e de suas
responsabilidades para protegê-los.
12.1.1 Atende a todos os requisitos do PCI DSS.
12.1.2 Inclui um processo anual que identifica ameaças e
vulnerabilidades, e resulta em uma avaliação de risco formal.
(Exemplos de metodologias de avaliação de risco incluem mas
não são limitados a OCTAVE, ISO 27005 e NIST SP 800-30.)
Uma avaliação de riscos permite a uma organização identificar ameaças e as
vulnerabilidades relacionadas que têm o potencial de causar um impacto negativo
em seus negócios. Os recursos podem então ser alocados com eficácia para
implementar controles que reduzem a probabilidade e/ou o impacto potencial da
ameaça em questão.
Realizar avaliações de riscos anuais permite à organização manter-se atualizada
com as mudanças organizacionais e ameaças, tendências e tecnologias em
evolução,
12.1.3 Inclui uma análise pelo menos uma vez por ano e
atualizações quando o ambiente é modificado.
12.2 Desenvolver procedimentos de segurança operacional
diariamente que estejam em conformidade com os requisitos
nessa especificação (por exemplo, procedimentos de
manutenção da conta do usuário e procedimentos de análise de
registros).
As ameaças de segurança e os métodos de proteção evoluem rapidamente ao
longo do ano. Sem atualizar a política de segurança para refletir essas alterações,
agora são abordadas novas medidas de proteção para lutar contra essas
ameaças.
Procedimentos diários de segurança operacional agem como “instruções de
mesa” para os trabalhadores usarem nas atividades diárias de manutenção e
administração do sistema. Os procedimentos de segurança operacional não
documentados levam a trabalhadores que não estão cientes do escopo total de
suas tarefas, processos que não podem ser repetidos com facilidade por novos
trabalhadores e possíveis falhas nesses processos que podem permitir que um
indivíduo mal-intencionado obtenha acesso a sistemas e recursos críticos.
Outubro de 2010
Página 61
Requisito
Orientação
12.3 Desenvolver políticas de utilização para tecnologias críticas
voltadas aos funcionários (por exemplo, tecnologias de acesso
remoto, tecnologias sem fio, mídia eletrônica removível, laptops,
dados pessoais/assistentes digitais (PDAs), uso de e-mail e uso
da Internet) para definir o uso adequado dessas tecnologias para
todos os funcionários e prestadores de serviços. Assegurar que
essas políticas de utilização exijam o seguinte:
As políticas de uso por funcionários podem ou proibir o uso de determinados
dispositivos e outras tecnologias, se for essa a política da empresa, ou fornecer
orientação para os funcionários quanto ao uso e à implementação corretos. Se
não estiverem em vigor políticas de uso, os funcionários podem usar as
tecnologias na violação da política da empresa, permitindo que indivíduos malintencionados consigam acesso a sistemas críticos e dados do titular do cartão.
Um exemplo pode ser configurar sem saber redes wireless sem segurança. Para
garantir que os padrões da empresa sejam seguidos e que somente as
tecnologias aprovadas sejam implementadas, pense em confinar a implementação
somente às equipes operacionais e não permitir que funcionários não
especializados/gerais instalem essas tecnologias.
12.3.1 Explicitar a aprovação por partes autorizadas
Sem exigir aprovação adequada da gestão para implementação dessas
tecnologias, um funcionário pode implementar inocentemente uma solução para
uma necessidade de negócios percebida, mas também abrir um grande buraco
que deixe os sistemas e dados críticos vulneráveis a indivíduos malintencionados.
12.3.2 Autenticação para o uso da tecnologia
Se a tecnologia for implementada sem autenticação adequada (IDs de usuário e
senhas, tokens, VPNs, etc.), indivíduos mal-intencionados podem facilmente usar
essa tecnologia desprotegida para acessar sistemas críticos e dados do titular do
cartão.
12.3.3 Uma lista de todos esses dispositivos e equipes com
acesso
Os indivíduos mal-intencionados podem violar a segurança física e colocar seus
próprios dispositivos na rede como “back door”, Um inventário preciso, com rótulos
adequados nos dispositivos, permite uma rápida identificação das instalações não
aprovadas. Pense em criar uma convenção de nomes oficiais para dispositivos e
rotule e registre todos os dispositivos de forma coerente com os controles de
inventário criados. Rótulos lógicos podem ser empregados, com informações
como códigos que podem ser associados ao proprietário, a informações de
contato e à sua finalidade.
12.3.4 Identificação dos dispositivos com proprietário,
informações de contato e finalidade
12.3.5 Usos aceitáveis da tecnologia
12.3.6 Locais de rede aceitáveis quanto às tecnologias
12.3.7Lista dos produtos aprovados pela empresa
12.3.8 Desconexão automática das sessões quanto às
tecnologias de acesso remoto após um período específico de
inatividade
12.3.9 Ativação de tecnologias de acesso remoto para
fornecedores e parceiros de negócio somente quando lhes for
Ao definir o uso corporativo aceitável e a localização dos dispositivos e da
tecnologia aprovados pela empresa, a empresa fica mais capaz de gerenciar e
controlar falhas nas configurações e nos controles operacionais, a fim de garantir
que não tenha sido aberta uma “back door” para um indivíduo mal-intencionado
obter acesso a sistemas críticos e a dados do titular do cartão.
As tecnologias de acesso remoto são frequentes "back doors" a recursos críticos e
a dados do titular do cartão. Ao desconectar as tecnologias de acesso remoto
quando não estiverem em uso (por exemplo, aquelas usadas para dar suporte aos
sistemas pelo POS ou por outros fornecedores), o acesso e os riscos à rede são
minimizados. Pense em usar controles para desconectar dispositivos depois de 15
minutos de inatividade. Veja também o Requisito 8.5.6 para saber mais sobre
Outubro de 2010
Página 62
Requisito
necessário, com desativação imediata após o uso
12.3.10 Para funcionários que acessam os dados do titular do
cartão por meio de tecnologias de acesso remoto, proibir a
cópia, a transferência e o armazenamento dos dados do titular
do cartão em discos rígidos locais e mídias eletrônicas
removíveis, exceto se explicitamente autorizado para uma
necessidade comercial definida.
Orientação
esse tópico.
Para garantir que os funcionários estejam cientes de suas responsabilidades de
não armazenar nem copiar dados do titular do cartão para o computador pessoal
local ou outras mídias, sua empresa deve contar com uma política que proíba
claramente essas atividades. Any such authorized personnel are responsible for
ensuring that cardholder data in their possession is handled in accordance with all
PCI DSS requirements, as that remote personnel’s environment is now considered
a part of the organization’s cardholder data environment.
12.4 Certificar-se de que a política e os procedimentos de
segurança definem claramente as responsabilidades quanto à
segurança das informações para todos os funcionários.
Sem papéis e responsabilidades claramente definidos e atribuídos, pode haver
uma interação inconsistente com o grupo de segurança, levando a uma
implementação não protegida de tecnologias ou ao uso de tecnologias não
protegidas ou desatualizadas.
12.5 Atribuir a um indivíduo ou a uma equipe as seguintes
responsabilidades de gerenciamento da segurança das
informações:
Cada pessoa ou equipe com responsabilidades pela gestão da segurança das
informações deve estar claramente ciente das responsabilidades e das tarefas
relacionadas por meio da política específica. Sem essa responsabilidade, falhas
nos processos podem dar acesso a recursos críticos ou dados do titular do cartão.
12.5.1 Definir, documentar e distribuir políticas e procedimentos
de segurança.
12.5.2 Monitorar e analisar os alertas e as informações de
segurança, e distribuir para as equipes apropriadas.
12.5.3 Definir, documentar e distribuir procedimentos de
resposta e escalação de incidentes de segurança para
assegurar que todas as situações sejam abordadas de modo
oportuno e eficiente.
12.5.4 Administrar as contas dos usuários, incluindo adições,
exclusões e modificações
12.5.5 Monitorar e controlar todos os acessos aos dados.
12.6Implementar um programa formal de conscientização da
segurança para conscientizar todos os funcionários sobre a
importância da segurança dos dados do titular do cartão.
Se os usuários não forem treinados sobre as responsabilidades de segurança, as
proteções e os processos que forem implementados poderão se tornar ineficazes
por causa de erros do funcionário ou ações não intencionais.
Outubro de 2010
Página 63
Requisito
12.6.1 Instruir os funcionários quando da contratação e pelo
menos uma vez por ano.
Observação: Os métodos podem variar dependendo da
função de cada funcionário e do nível de acesso aos dados do
titular do cartão.
Orientação
Se o programa de conscientização de segurança não incluir sessões de
atualização anuais, os principais processos e procedimentos de segurança
poderão ser esquecidos ou ignorados, resultando em exposição dos recursos
críticos e dos dados do titular do cartão. O foco e a profundidade do treinamento
inicial e de atualização podem variar de acordo com a função dos funcionários e
devem ser personalizados conforme necessário para o público específico. Por
exemplo, sessões para administradores de bancos de dados podem concentrar-se
em processos e controles técnicos específicos, enquanto o treinamento para os
caixas pode ser focado procedimentos seguros de transações
Considere incluir atualizações constantes de conscientização para manter os
funcionários atualizados com os procedimentos e as políticas atuais. O método de
instrução também deve variar de acordo com o público específico ou o
treinamento sendo apresentado. Por exemplo, o treinamento inicial e anual pode
ser apresentado em uma sessão formal de treinamento prático em um
computador, enquanto as atualizações periódicas podem ser apresentadas por email, postêres, boletins informativos etc.
12.6.2 Exigir que os funcionários reconheçam, pelo menos uma
vez por ano, que leram e compreenderam a política e os
procedimentos de segurança da empresa.
12.7 Analise bem os potenciais funcionários antes de contratar
para minimizar o risco de ataques a partir de fontes internas.
(Exemplos de verificações da formação incluem o histórico do
emprego anterior, ficha criminal, histórico de crédito e
verificações das referências.)
Observação: Para os funcionários como caixas de loja que têm
acesso somente a um número do cartão por vez ao viabilizar
uma transação, esse requisito é apenas uma recomendação.
por escrito ou eletronicamente) ajuda a garantir que eles tenham lido e entendido
as políticas e os procedimentos de segurança e que eles tenham se
comprometido a obedecer a essas políticas.
Executar investigações de histórico completas antes de contratar funcionários que
se esperam ter acesso aos dados do titular do cartão reduz o risco do uso não
autorizado de PANs e outros dados do titular do cartão por pessoas com históricos
questionáveis ou criminais. Espera-se que uma empresa tenha uma política e um
processo para verificações de histórico, incluindo o próprio processo de decisão
para o qual os resultados da verificação do histórico tenham impacto sobre as
decisões de contratação (e qual seria esse impacto).
Para ser eficaz, o nível de verificação do histórico deve ser adequado ao cargo em
particular. Por exemplo: os cargos que exijam maior responsabilidade ou que
possuam acesso de administrador a dados ou sistemas importantes poderão
garantir verificações de background mais detalhadas do que os cargos que
exigirem menos responsabilidade e possuírem nível inferior de acesso. Também
poderá não ser adequado ao processo cobrir transferências internas, em que as
pessoas que ocuparem cargos de risco mais baixo e que ainda não tiverem
passado por uma verificação de background detalhada são promovidas ou
transferidas para cargos de maior responsabilidade ou nível de acesso.
Outubro de 2010
Página 64
Requisito
Orientação
12.8 Se os dados do titular do cartão forem compartilhados com
prestadores de serviços, manter e implementar políticas e
procedimentos para gerenciar os prestadores de serviços,
incluindo o seguinte:
Se o comerciante ou o prestador de serviço compartilhar os dados do titular do
cartão com um prestador de serviço, devem ser aplicados certos requisitos para
garantir a proteção contínua desses dados por tais prestadores de serviço.
12.8.1 Manter uma lista dos prestadores de serviços.
Rastrear todos os provedores de serviço identifica quando possíveis riscos se
estenderem para fora da organização.
12.8.2 Manter um acordo por escrito que inclua um
reconhecimento de que os prestadores de serviços são
responsáveis pela segurança dos dados do titular do cartão
que eles possuírem.
O reconhecimento dos prestadores de serviço evidencia o compromisso deles
com manter uma segurança adequada dos dados do titular do cartão que são
obtidos dos clientes e, assim, responsabiliza-os.
12.8.3 Certificar-se de que haja um processo definido para a
contratação dos prestadores de serviços, incluindo uma
diligência devida adequada antes da contratação.
O processo garante que qualquer envolvimento de um prestador de serviço seja
totalmente vetado internamente pela organização, que deve incluir uma análise de
risco antes de estabelecer um relacionamento formal com o prestador de serviços.
12.8.4 Manter um programa para monitorar o status de
conformidade quanto ao PCI DSS dos prestadores de serviços.
Conhecer o status de conformidade do prestador de serviço com o PCI DSS
fornece uma garantia a mais de que eles estão de acordo com os mesmos
requisitos aos quais a organização está sujeita.
Se o provedor oferecer diversos serviços, este requisito se aplicará apenas aos
serviços realmente prestados ao cliente, e apenas os serviços que estiverem
dentro do escopo da avaliação de PCI DSS do cliente. Por exemplo: se um
provedor oferecer serviços de firewall/IDS e ISP, um cliente que utilizar o serviço
de firewall/IDS incluirá este serviço apenas no escopo da avaliação de PCI DSS.
12.9 Implementar um plano de resposta a incidentes. Preparar-se
para responder imediatamente a uma falha no sistema.
Sem um plano de resposta a incidentes de segurança completo que seja
adequadamente disseminado, lido e entendido pelas partes responsáveis, a
confusão e a falta de uma resposta unificada podem criar mais tempo ocioso para
a empresa, exposição pública desnecessária e novas responsabilidades legais.
Outubro de 2010
Página 65
Requisito
Orientação
12.9.1 Criar o plano de resposta a incidentes para ser
implementado no caso de violações do sistema. Certificar-se
de que o plano aborda o seguinte, pelo menos:
Funções, responsabilidades e estratégias de comunicação
e contato no caso de um comprometimento, incluindo a
notifcação às bandeiras de pagamento, pelo menos
Procedimentos de resposta específicos a incidentes
Procedimentos de recuperação e continuidade dos
negócios
Processos de back-up dos dados
Análise dos requisitos legais visando ao relato dos
comprometimentos
Abrangência e resposta de todos os componentes críticos
do sistema
Referência ou inclusão de procedimentos de resposta a
incidentes por parte das bandeiras de pagamento
O plano de resposta a incidentes deve ser completo e conter todos os elementoschave para permitir que sua empresa reaja com eficiência no caso de uma
violação que possa causar impacto nos dados do titular do cartão.
12.9.2 Testar o plano pelo menos uma vez por ano.
Sem testes adequados, etapas essenciais podem ser perdidas, o que poderia
aumentar a exposição durante um incidente.
Se ao longo do último ano o plano de resposta incidental tiver sido inteiramente
ativado, bastará uma revisão detalhada do incidente real e de sua resposta para
que o teste seja adequado. Caso apenas alguns componentes do plano tenham
sido ativados recentemente, os componentes restantes ainda precisarão ser
testados. Caso nenhum componente do plano tenha sido ativado nos últimos 12
meses, todos os componentes do plano deverão ser testados.
12.9.3 Designar equipes específicas para estarem disponíveis
em tempo integral para responder aos alertas.
12.9.4Fornecer o treinamento adequado à equipe que é
responsável pela resposta às falhas do sistema.
Sem uma equipe de reação a incidentes treinada e prontamente disponível,
podem ocorrer danos extensos à rede, e dados e sistemas críticos podem ficar
“poluídos” pelo manuseio inadequado dos sistemas almejados. Isso pode evitar o
sucesso de uma investigação pós-incidente. Se não estiverem disponíveis
recursos internos, pense em contratar um fornecedor que os forneça.
12.9.5 Incluir alertas de sistemas de detecção de invasão,
prevenção contra invasões e monitoramento da integridade dos
arquivos.
Esses sistemas de monitoramento são feitos para se concentrar em possíveis
riscos aos dados, são essenciais para se tomar uma ação rápida para evitar uma
violação e devem estar incluídos nos processos de resposta a incidentes.
Desenvolver um processo para modificar e aprimorar o plano
de resposta a incidentes, de acordo com as lições aprendidas e
para incorporar os desenvolvimentos do setor.
Incorporar as “lições aprendidas” no plano de reação a incidentes depois de um
incidente ajuda a manter o plano atualizado e capaz de reagir às ameaças que
surgirem e às tendências de segurança.
Outubro de 2010
Página 66
Orientação para o Requisito A.1: Requisitos adicionais do PCI DSS para provedores de hospedagem
compartilhada
Requisito A.1: Os provedores de hospedagem compartilhada protegem o ambiente de dados do titular do cartão
Conforme mencionado no Requisito 12.8, todos os prestadores de serviços com acesso aos dados do titular do cartão (incluindo os provedores
de hospedagem compartilhada) devem seguir o PCI DSS. Além disso, o Requisito 2,4 afirma que os provedores de hospedagem compartilhada
devem proteger o ambiente hospedado e os dados de cada entidade. Portanto, os provedores de hospedagem compartilhada também devem
estar em conformidade com os requisitos nesse Apêndice.
Requisito
Orientação
A.1 Proteja o ambiente hospedado e os dados de cada entidade
(seja comerciante, prestador de serviços ou outra entidade),
de acordo com os itens A.1.1 a A.1.4:
Um provedor de hospedagem deve atender a esses
requisitos, assim como a todas as outras seções relevantes
do PCI DSS.
Observação: Embora um provedor de hospedagem possa
atender a esses requisitos, a conformidade da entidade de
que utiliza o provedor de hospedagem não é assegurada.
Cada entidade deve estar em conformidade com o PCI DSS
e validar a conformidade, conforme aplicável.
O Anexo A do PCI DSS é destinado a provedores de hospedagem compartilhada
que desejam fornecer aos clientes do comerciante e/ou prestador de serviço um
ambiente de hospedagem em conformidade com o PCI DSS. Essas etapas devem
ser cumpridas, além de todos os outros requisitos relevantes do PCI DSS.
A.1.1 Certificar-se de que cada entidade executa somente
os processos que têm acesso ao ambiente de dados
do titular do cartão daquela entidade.
Se um comerciante ou prestador de serviço puder executar seus aplicativos
próprios no servidor compartilhado, eles devem ser executados com o ID de
usuário do comerciante ou prestador de serviço, e não como um usuário
privilegiado. O usuário privilegiado pode ter acesso aos ambientes de dados do
titular do cartão de todos os outros comerciantes e prestadores de serviço, além
dos seus próprios.
A.1.2 Restringir o acesso e os privilégios de cada entidade
somente ao próprio ambiente de dados do titular do
cartão.
Para garantir que os acessos e os privilégios estejam restritos, de forma que cada
comerciante ou prestador de serviço só tenha acesso ao próprio ambiente dos
dados do titular do cartão, considere o seguinte: (1) privilégios do ID de usuário do
servidor da Web do comerciante ou do prestador de serviço; (2) permissões
concedidas para ler, gravar e executar arquivos; (3) permissões concedidas para
gravar em binários do sistema; (4) permissões concedidas aos arquivos de log do
comerciante e do prestador de serviço; e (5) controles para garantir que um
comerciante ou prestador de serviço não possa monopolizar os recursos do
sistema.
A.1.3 Certificar-se de que os registros e as trilhas de
auditoria estão ativadas e são exclusivas para o
ambiente de dados do titular do cartão de cada
Os logs devem estar disponíveis em um ambiente de hospedagem compartilhado,
de forma que os comerciantes e prestadores de serviço tenham acesso e
Outubro de 2010
Página 67
Requisito
entidade, além de estarem em conformidade com o
Requisito 10 do PCI DSS.
A.1.4 Permitir que os processos providenciem uma
investigação forense oportuna no caso de um
comprometimento em qualquer comerciante ou
prestador de serviços hospedado.
Orientação
consigam analisar os logs específicos ao ambiente dos dados do titular do cartão.
Os provedores de hospedagem compartilhada devem ter processos para fornecer
uma resposta rápida e fácil no caso de uma investigação forense ser necessária
para um comprometimento, até o nível adequado de detalhes, de forma que os
detalhes individuais do comerciante ou do prestador de serviço estejam
disponíveis.
Outubro de 2010
Página 68
Anexo A: Padrão de segurança de dados do PCI: documentos relacionados
Os documentos a seguir foram criados para auxiliar comerciantes e prestadores de serviço a entenderem o Padrão de segurança de dados do
PCI e as responsabilidades e requisitos de conformidade.
9
Documento
Público
Requisitos dos Padrões de Segurança de Dados do PCI e
Procedimentos de Avaliação da Segurança
Todos os comerciantes e prestadores de serviço
Navegando pelo PCI DSS: Conheça a intenção dos requisitos
Padrão de segurança de dados do PCI: Diretrizes e instruções do
Questionário de auto-avaliação
Padrão de segurança de dados do PCI: Questionário A de autoavaliação e atestado
Comerciantes qualificados
9
Padrão de segurança de dados do PCI: Questionário B de autoavaliação e atestado
9
Padrão de segurança de dados do PCI: Questionário C-VT de autoavaliação e atestado
9
Padrão de segurança de dados do PCI: Questionário C de autoavaliação e atestado
9
Padrão de segurança de dados do PCI: Questionário D de autoavaliação e atestado
Comerciantes e prestadores de serviço qualificados
Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS
9
Para determinar o Questionário de auto-avaliação adequado, veja Padrão de segurança de dados do PCI: Diretrizes e instruções do Questionário de auto-avaliação, “Selecionando
o SAQ e certificado que melhor se aplicam à sua organização”.
Outubro de 2010
Página 69

Navegando pelo PCI DSS

Transcrição

Documentos relacionados

Autorização de Débito Intercambio Global Master e Dinners

AUTORIZAÇÃO DE DÉBITO EM CARTÃO DE CRÉDITO Conforme

AUTORIZAÇÃO DE DÉBITO - SERVIÇOS DE VIAGENS

AUTORIZAÇÃO DE DÉBITO - SERVIÇOS DE

AUTORIZAÇÃO DE DÉBITO – SERVIÇOS DE VIAGEM

americanexpress.ca minha conta

Cartão de crédito: Visa, MasterCard, American Express, Diners

como associar o cartão de estudante

solicitação de reembolso

autorização de débito em cartão de crédito