PCI DSS V3-Signed

Indstria de cartes de pagamento (PCI)
Padro de Segurana de Dados

Requisitos e procedimentos da avaliao de
segurana
Verso 3.0
Novembro de 2013

Padro de segurana de dados da Indstria de cartes de pagamento (PCI), v3.0 Pgina 2
2006-2013 PCI Security Standards Council, LLC. Todos os direitos reservados. Novembro de 2013
Alteraes no documento
Data Verso Descrio Pginas
Outubro de 2008 1.2
Introduzir PCI DSS v1.2 como Requisitos e procedimentos de avaliao da segurana do PCI
DSS, eliminando a redundncia entre os documentos e fazer mudanas gerais e especficas de
Procedimentos de auditoria de segurana do PCI DSS v1.1. Para obter informaes completas,
consulte Resumo de alteraes no padro de segurana de dados do PCI do PCI DSS Verso
1.1 para 1.2.

Julho de 2009 1.2.1
Adicionar sentena que foi excluda incorretamente entre o PCI DSS v1.1 e v1.2. 5
Corrigir grafia nos procedimentos de teste 6.3.7.a e 6.3.7.b. 32
Remover marca cinza nas colunas implantado e no implantado nos procedimentos de teste
6.5.b.
33
Para a Planilha de controles de compensao exemplo completo, corrigir o texto no alto da
pgina para Use esta planilha para definir os controles de compensao para qualquer requisito
indicado como implantado via controles de compensao.
64
Outubro de 2010 2.0
Atualizar e implementar as alteraes da v1.2.1. Consulte Resumo de alteraes do PCI DSS
a partir da verso 1.2.1 para a 2.0 do PCI-DSS.

Novembro de
2013
3.0
Atualizar a partir da v2.0. Consulte Resumo de alteraes do PCI DSS a partir da verso 2.0
para a 3.0 do PCI-DSS.

ndice
Alteraes no documento ................................................................................................................................................................. 2
Introduo e viso geral do padro de segurana de dados do PCI.............................................................................................. 5
Recursos PCI DSS ...................................................................................................................................................................................................... 6
Informaes de aplicabilidade do PCI DSS ...................................................................................................................................... 7
Relao entre PCI DSS e PA-DSS ..................................................................................................................................................... 9
Aplicabilidade do PCI DSS para aplicativos PA-DSS ................................................................................................................................................. 9
Aplicabilidade do PCI DSS para fornecedores de aplicativos de pagamento ............................................................................................................ 9
Escopo dos requisitos do PCI DSS ................................................................................................................................................ 10
Segmentao da rede ............................................................................................................................................................................................... 11
Sem fio 11
Uso dos prestadores de servios terceirizados/terceirizao ................................................................................................................................... 12
Melhores prticas para implementar o PCI DSS nos processos de cenrios de referncia ...................................................... 13
Para os assessores: Amostragem de reas de negcios e componentes do sistema ............................................................... 15
Controles de compensao ............................................................................................................................................................ 16
Instrues e contedo para o relatrio sobre conformidade ....................................................................................................... 17
Processo de avaliao do PCI DSS ................................................................................................................................................ 17
Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana ...................................................................... 18
Construir e manter a segurana de rede e sistemas ............................................................................................................................................ 19
Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do portador do carto ................................................ 19
Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana ................... 28
Proteger os dados do portador do carto ............................................................................................................................................................. 35
Requisito 3: Proteger os dados armazenados do portador do carto ............................................................................................................. 35
Requisito 4: Criptografe a transmisso dos dados do portador do carto em redes abertas e pblicas ....................................................... 47
Manter um programa de gerenciamento de vulnerabilidades ............................................................................................................................. 50
Requisito 5: Proteja todos os sistemas contra softwares prejudiciais e atualize regularmente programas ou software de antivrus ............ 50
Requisito 6: Desenvolver e manter sistemas e aplicativos seguros ............................................................................................................... 54
Implemente medidas rigorosas de control e de acesso ....................................................................................................................................... 69
Requisito 7: Restrinja o acesso aos dados do portador do carto de acordo com a necessidade de conhecimento para o negcio ........... 69
Requisito 8: Identifique e autentique o acesso aos componentes do sistema ............................................................................................... 72

Requisito 9: Restrinja o acesso fsico aos dados do portador do carto ........................................................................................................ 82
Monitorar e testar as redes regul armente.............................................................................................................................................................. 93
Requisito 10: Acompanhe e monitore todos os acessos com relao aos recursos da rede e aos dados do portador do carto .................. 93
Requisito 11: Testar regularmente os sistemas e processos de segurana................................................................................................... 101
Manter uma poltica de segurana de informaes ............................................................................................................................................ 111
Requisito 12: Mantenha uma poltica que aborde a segurana da informao para todas as equipes. ................................................................ 111
Apndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada ................................. 122
Requisito A.1: Os provedores de hospedagem compartilhada devem proteger o ambiente de dados do portador do carto .............................. 122
Apndice B: Controles de compensao .............................................................................................................................. 125
Apndice C: Planilha dos controles de compensao ........................................................................................................ 127
Apndice D: Segmentao e amostragem de reas de negcios/componentes do sistema ............................................ 129

Introduo e viso geral do padro de segurana de dados do PCI
O Padro de Segurana de Dados da Indstria de Cartes de Pagamento (PCI DSS) foi desenvolvido para incentivar e aprimorar a segurana
dos dados do portador do carto e promover a ampla adoo de medidas de segurana de dados consistentes no mundo todo. O PCI DSS
oferece a base de requisitos tcnicos e operacionais elaborados para proteger os dados do portador do carto. O PCI DSS se aplica a todas as
entidades envolvidas nos processos de pagamento do carto inclusive comerciantes, processadores, adquirentes, emissores e prestadores de
servio, bem como todas as entidades que armazenam, processam ou transmitem os dados do portador do carto (CHD) e/ou dados de
autenticao confidenciais (SAD). Abaixo, h uma viso geral de alto nvel dos 12 requisitos do PCI DSS.

Este documento, Requisitos dos Padro de Segurana de Dados do PCI e Procedimentos de Avaliao da Segurana, usa como base os 12
requisitos do PCI DSS e combina-os com procedimentos de testes correspondentes em uma ferramenta de avaliao de segurana. Ele foi
projetado para o uso durante as avaliaes de conformidade PCI DSS como parte do processo de validao de uma entidade. As seguintes

sees oferecem orientaes e as melhores prticas para auxiliar entidades a conduzir, relatar e se preparar para os resultados de uma
avaliao PCI DSS. Os requisitos e procedimentos de teste do PCI DSS se iniciam na pgina 15.
O PCI DSS compreende um conjunto mnimo de requisitos para proteger os dados do portador do carto e pode ser aperfeioado por controles e
prticas adicionais para amenizar ainda mais os riscos, bem como as normas e leis locais, regionais e do setor. Alm disso, os requisitos legais
ou regulatrios podem exigir proteo especfica de informaes pessoalmente identificveis ou outros elementos de dados (por exemplo, o
nome do portador do carto). O PCI DSS no substitui as leis locais ou regionais, normas governamentais ou outros requisitos legais.
Recursos PCI DSS
O site do PCI Security Standards Council (PCI SSC) (www.pcisecuritystandards.org) contm alguns recursos adicionais para auxiliar as
organizaes com suas avaliaes e validaes do PCI DSS, inclusive:
Biblioteca de documentos, incluindo:
o PCI DSS Resumo de alteraes a partir da verso 2.0 para a 3.0 do PCI-
DSS.
o Guia de referncia rpida do PCI DSS
o Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS
o Suplementos informativos e orientaes
o Abordagem priorizada para o PCI DSS
o Relatrio de conformidade (ROC) Modelo de relatrio e Instrues de relatrio
o Questionrios de autoavaliao (SAQs) e diretrizes e instrues do SAQ
o Atestados de conformidade (AOCs)
Perguntas frequentes (FAQs)
PCI para sites de pequenos comerciantes
Treinamentos e seminrios online do PCI
Lista de assessores de segurana qualificados (QSAs) e fornecedores de varredura aprovados (ASVs)
Lista de dispositivos PTS aprovados e aplicativos PA-DSS de pagamento validados
Consulte www.pcisecuritystandards.org para obter informaes sobre estes e outros recursos.
Observao: Os suplementos informativos
complementam o PCI DSS e identificam
consideraes adicionais e
recomendaes para atender aos
requisitos do PCI DSSeles no alteram,
eliminam ou sobrepem o PCI DSS ou
qualquer de seus requisitos.

Informaes de aplicabilidade do PCI DSS
O PCI DSS se aplica a todas as entidades envolvidas nos processos de pagamento do carto, inclusive comerciantes, processadores e
prestadores de servio, bem como todas as entidades que armazenam, processam ou transmitem os dados do portador do carto e/ou dados de
autenticao confidenciais.
Os dados do portador do carto e os dados de autenticao confidenciais so definidos conforme segue:

Dados contbeis
Os dados do portador do carto incluem:
Os dados de autenticao confidenciai s
incluem:
O nmero da conta principal (PAN)
Nome do portador do carto
Data de vencimento
Cdigo de servio
Dados de rastreamento completo
(dados em tarja magntica ou
equivalentes em chip)
CAV2/CVC2/CVV2/CID
PINs/Bloqueios de PIN

O primei ro nmero contbil o fator determinante para os dados do portador do carto. Se o nome, cdigo de servio e/ou data de
validade de um portador do carto so armazenados, processados ou transmitidos com o PAN ou, de outro modo, esto presentes no
ambiente de dados do portador do carto, eles devem ser protegidos de acordo com os requisitos aplicveis do PCI DSS.
Os requisitos do PCI DSS se aplicam a organizaes e ambientes onde os dados contbeis (dados do portador do carto e/ou dados de
autenticao confidenciais) sejam armazenados, processados ou transmitidos. Alguns requisitos do PCI DSS tambm podem ser aplicveis a
organizaes que tenham terceirizado suas operaes de pagamento ou o gerenciamento de seu CDE
1
. Alm disso, as organizaes que
terceirizam seu CDE ou operaes de pagamento para terceiros so responsveis por garantir que os dados contbeis sejam protegidos por
este terceiro conforme os requisitos aplicveis do PCI DSS.
A tabela a seguir ilustra os elementos comumente usados do portador do carto e dados de autenticao confidenciais, se o armazenamento de
cada elemento de dados permitido ou proibido e se cada elemento de dados deve ser protegido. Essa tabela no completa, mas exibida
para ilustrar os diferentes tipos de requisitos que se aplicam a cada elemento de dados.

1
De acordo com os programas em conformidade com a empresa de pagamento individual


Elemento de dados
Armazenamento
permitido
Converter dados armazenados ilegveis
conforme Requi sito 3.4
D
a
d
o
s

c
o
n
t
b
e
i
s
Dados do
portador do
carto
O nmero da conta principal
(PAN)
Sim Sim
Nome do portador do carto Sim No
Cdigo de servio Sim No
Data de vencimento Sim No
Dados de
autenticao
confidenciai s
2

Dados de rastreamento
completo
3

No No armazenvel conforme Requisito 3.2
CAV2/CVC2/CVV2/CID
4
PIN/Bloco de PIN
5

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 portador do
carto, somente o PAN dever ser convertido como ilegvel de acordo com o Requisito 3.4 do PCI DSS.
Dados de autenticao confidenciais no devem ser armazenados aps a autorizao, mesmo se forem criptografados. Isso se aplica mesmo
onde no h PAN no ambiente. As organizaes devem entrar em contato diretamente com seu adquirente ou empresa de pagamento para
saber se permitido armazenar o SAD antes da autorizao, por quanto tempo e quaisquer requisitos de proteo e utilizao.

2
Os dados de autenticao confidenciais no devem ser armazenados aps a autorizao (mesmo se forem criptografados).
3
Dados de rastreamento completo da tarja magntica, dados equivalentes no chip, ou em outro lugar
4
O valor de trs ou quatro dgitos impresso na frente ou atrs de um carto de pagamento
5
Nmero de identificao pessoal inserido pelo portador do carto durante uma transao com carto e/ou bloqueio de PIN criptografado dentro da mensagem
da transao

Relao entre PCI DSS e PA-DSS
Aplicabilidade do PCI DSS para aplicativos PA-DSS
O uso de um aplicativo compatvel com o Padro de Segurana de Dados de Formulrio de Pagamento (PA-DSS) no torna uma entidade
compatvel com o PCI DSS por si s, uma vez que o aplicativo deve ser implementado em um ambiente compatvel com o PCI DSS e de acordo
com o Guia de implementao do PA-DSS oferecido pelo fornecedor do aplicativo de pagamento.
Todos os aplicativos que armazenam, processam ou transmitem dados do portador do carto abrangem uma avaliao do PCI DSS da entidade,
incluindo aplicativos que tenham sido validados para PA-DSS. A avaliao do PCI DSS deve verificar se o aplicativo de pagamento validado do
PA-DSS est configurado adequadamente e implementado com segurana conforme os requisitos do PCI DSS. Se o aplicativo de pagamento
tiver passado por qualquer customizao, uma reviso mais detalhada ser exigida durante a avaliao do PCI DSS, j que o aplicativo pode no
ser mais caracterstico da verso que foi validada para o PA-DSS.
Os requisitos do PA-DSS derivam-se dos Requisitos do PCI DSS e dos procedimentos de avaliao da segurana (definidos neste documento).
O PA-DSS detalha os requisitos que um aplicativo de pagamento deve atender para facilitar a conformidade do PCI DSS de um cliente.
Os aplicativos de pagamento seguro, quando implementados em um ambiente compatvel com PCI-DSS, minimizaro as possibilidades de
quebras na segurana, levando ao comprometimento do PAN, dados de rastreamento completo, cdigos e valores de validao do carto (CAV2,
CID, CVC2 e CVV2), PINs e bloqueios de PIN e a fraudes destruidoras resultantes dessas quebras.
Para determinar se o PA-DSS se aplica a um determinado aplicativo de pagamento, consulte o Guia do programa PA-DSS que pode ser
encontrado no site www.pcisecuritystandards.org.
Aplicabilidade do PCI DSS para fornecedores de aplicativos de pagamento
O PCI DSS pode se aplicar a fornecedores de aplicativos de pagamentos se estes armazenam, processam ou transmitem dados do portador do
carto, ou se tiverem acesso aos dados do portador do carto de seus clientes (por exemplo, na funo de um prestador de servios).

Escopo dos requisitos do PCI DSS
Os requisitos de segurana do PCI DSS se aplicam a todos os componentes do sistema que estejam includos ou conectados no ambiente dos
dados do portador do carto. O ambiente de dados do portador do carto (CDE) compreende pessoas, processos e tecnologias que armazenam,
processam, ou transmitem os dados do portador do carto ou dados de autenticao confidenciais. Os "componentes do sistema" incluem
dispositivos de rede, servidores, dispositivos de computao e aplicativos. Exemplos de componentes do sistema incluem, entre outros, o
seguinte:
Sistemas que oferecem servios de segurana (por exemplo, servidores de autenticao), facilitam a segmentao (por exemplo,
firewalls internos) ou podem impactar a segurana do CDE (por exemplo, servidores de redirecionamento de rede ou resoluo de
nome).
Componentes de virtualizao como mquinas virtuais, switches/roteadores virtuais, mecanismos virtuais, aplicativos/desktops virtuais e
hipervisores.
Os componentes de rede incluem, entre outros, firewalls, switches, roteadores, pontos de acesso sem fio, dispositivos de rede e outros
dispositivos de segurana.
Os tipos de servidor incluem, entre outros, Web, aplicativo, banco de dados, autenticao, e-mail, proxy, NTP (Network Time Protocol) e
DNS (Domain Name Server).
Os aplicativos incluem todos os aplicativos adquiridos e personalizados, incluindo os aplicativos internos e externos (internet, por
exemplo).
Qualquer outro componente ou dispositivo localizado dentro ou conectado ao CDE
A primeira etapa de uma avaliao do PCI DSS determinar precisamente o escopo da reviso. Ao menos anualmente e antes da avaliao
anual, a entidade deve confirmar a preciso de seu escopo do PCI DSS ao identificar todos os locais e fluxos de dados do portador do carto e
assegurar que estejam includos no escopo do PCI DSS. Para confirmar a preciso e a adequao do escopo do PCI DSS, execute o seguinte:
A entidade avaliada identifica e documenta a existncia de todos os dados do portador do carto em seu ambiente, para verificar se
nenhum dado do portador do carto existe fora do CDE definido no momento.
Assim que todos os locais dos dados do portador do carto forem identificados e documentados, a entidade usa os resultados para
verificar se o escopo do PCI DSS adequado (por exemplo, os resultados podem ser um diagrama ou um inventrio de locais de dados
do portador do carto).
A entidade considera que quaisquer dados do portador do carto encontrados esto no escopo da avaliao do PCI DSS e so parte do
CDE. Se a entidade identificar dados que no estejam atualmente includos no CDE, estes dados devem ser apagados com segurana,
migrados para o CDE definido atualmente ou para o CDE redefinido para incluir estes dados.
A entidade retm a documentao que mostra como o escopo do PCI DSS foi determinado. A documentao retida para a reviso da
assessoria e/ou para referncia durante a prxima atividade anual de confirmao do escopo do PCI DSS.
Para cada avaliao do PCI DSS, necessrio que o assessor valide que o escopo da avaliao est corretamente definido e documentado.

Segmentao da rede
A segmentao da rede ou o isolamento (separao) do ambiente de dados do portador do carto do restante da rede corporativa no um
requisito do PCI DSS. Entretanto, ela recomendada como um mtodo que pode reduzir:
O escopo da avaliao do PCI DSS
O custo da avaliao do PCI DSS
O custo e a dificuldade de implementar e manter controles do PCI DSS
O risco de uma empresa (reduzido pela consolidao dos dados do portador do carto em locais mais controlados e que totalizam um
nmero menor)
Sem a segmentao adequada da rede (s vezes chamada de "rede plana"), toda a rede est no escopo da avaliao do PCI DSS. A
segmentao da rede pode ser realizada por meio de firewalls internos da rede, roteadores com listas de controle de acesso rigorosas ou outras
tecnologias que restringem o acesso a um determinado segmento de uma rede. Para ser considerado fora do escopo para o PCI DSS, um
componente de sistema deve estar adequadamente isolado (segmentado) do CDE, de forma que mesmo se o componente de sistema fora do
escopo estivesse comprometido, ele no poderia impactar na segurana do CDE.
Um pr-requisito importante para reduzir o escopo do ambiente de dados do portador do carto uma compreenso clara das necessidades do
negcio e dos processos relacionados ao armazenamento, processamento ou transmisso dos dados do portador do carto. Restringir os dados
do portador do carto menor quantidade de locais possvel ao eliminar dados desnecessrios e consolidar os dados necessrios talvez exija a
reformulao de prticas de negcios de longa data.
Documentar os fluxos dos dados do portador do carto por meio de um diagrama de fluxo de dados ajuda a compreender totalmente todos os
fluxos de dados do portador do carto e assegura que qualquer segmentao de rede seja eficiente no isolamento do ambiente de dados do
portador do carto.
Se a segmentao da rede tiver sido implementada e sendo usada para reduzir o escopo da avaliao do PCI DSS, o assessor dever verificar
se a segmentao adequada para diminuir o escopo da avaliao. Em um nvel elevado, a segmentao adequada da rede isola os sistemas
que armazenam, processam ou transmitem dados do portador do carto dos outros sistemas. Entretanto, a adequao de uma implementao
especfica da segmentao da rede varia muito e depende de certos fatores, como uma determinada configurao de rede, das tecnologias
implementadas e de outros controles que podem ser empregados.
Apndice D: A segmentao e a amostragem dos componentes de sistema/reas de negcio oferece mais informaes sobre o efeito da
segmentao e da amostragem da rede no escopo das avaliaes do PCI DSS.
Sem fio
Se uma tecnologia sem fio for usada para armazenar, processar ou transmitir dados do portador do carto (por exemplo, transaes do ponto de
venda, "quebra de linha") ou se uma WLAN (Wireless Local Area Network) for parte do ou estiver conectada ao ambiente de dados do portador
do carto, os requisitos do PCI DSS e os procedimentos de teste para ambientes sem fio se aplicaro e devero ser realizados (por exemplo,

Requisitos 1.2.3, 2.1.1 e 4.1.1). Antes da tecnologia sem fio ser implementada, uma entidade deve avaliar cuidadosamente a necessidade da
tecnologia com relao ao risco. Considere a implementao da tecnologia sem fio somente para a transmisso de dados no confidenciais.
Uso dos prestadores de servios terceirizados/terceirizao
Para prestadores de servios que devem realizar uma avaliao in loco anual, a validao da conformidade deve ser desempenhada em todos os
componentes do sistema no ambiente dos dados do portador do carto.
Um prestador de servios ou comerciante pode usar um provedor terceirizado para armazenar, processar ou transmitir dados do portador do
carto em seu nome ou gerenciar componentes como roteadores, firewalls, bancos de dados, segurana fsica e/ou servidores. Se for o caso,
talvez haja um impacto na segurana do ambiente de dados do portador do carto.
As partes devem identificar claramente os servios e componentes do sistemas que so includos no escopo da avaliao do PCI DSS do
prestador de servios, os requisitos especficos do PCI DSS abrangidos pelo prestador de servios e quaisquer requisitos que os clientes do
prestador de servios sejam responsveis por incluir em suas prprias revises do PCI DSS. Por exemplo, um provedor de hospedagem
gerenciada deve definir claramente quais de seus endereos IP so mapeados como parte de seu processo trimestral de varredura da
vulnerabilidade e quais endereos IP os clientes so responsveis por incluir em suas prprias varreduras trimestrais.
H duas opes para que os prestadores de servios terceirizados comprovem a conformidade:
1) Eles podem ser submetidos a uma avaliao do PCI DSS por vontade prpria e fornecer evidncias de sua conformidade a seus clientes;
ou
2) Caso no se submetam avaliao do PCI DSS, ser necessrio que tenham seus servios analisados durante o curso de cada
avaliao do PCI DSS de seus clientes.
Se o terceiro realizar sua prpria avaliao do PCI DSS, ele deve fornecer evidncias suficientes aos seus clientes para certificar que o escopo
da avaliao do PCI DSS do prestador de servios incluiu os servios aplicveis ao cliente e que os requisitos relevantes do PCI DSS foram
examinados e determinados como adequados. O tipo especfico de evidncia fornecida pelo prestador de servios aos seus clientes depender
dos acordos/contratos em vigor entre as partes. Por exemplo, fornecer o AOC e/ou sees relevantes do ROC do prestador de servios (redigido
para proteger qualquer informao confidencial) pode ajudar a fornecer toda ou alguma informao.
Alm disso, os comerciantes e prestadores de servios devem gerenciar e monitorar a conformidade do PCI DSS de todos os terceiros
associados quanto ao acesso aos dados do portador do carto. Para obter detalhes, consulte o Requisito 12.8 nesse documento.

Melhores prticas para implementar o PCI DSS nos processos de cenrios de
referncia
Para assegurar que os controles de segurana continuem a ser adequadamente implementados, o PCI DSS deve ser implementado nas
atividades do cenrio de referncia BAU (Business-As-Usual) como parte de uma estratgia global de segurana da entidade. Isso possibilita que
uma entidade monitore a efetividade de seus controles de segurana continuamente e mantenha seu ambiente compatvel com o PCI DSS entre
as avaliaes do PCI DSS. Exemplos de como o PCI DSS deve ser incorporado nas atividades BAU incluem, entre outros:
1. Monitoramento de controles de segurana (como firewalls, sistemas de deteco de invaso/sistemas de preveno contra invaso
(IDS/IPS), monitoramento da integridade do arquivo (FIM), antivrus, controles de acesso, etc.) para assegurar que eles estejam
funcionando de maneira efetiva e conforme o planejado.
2. Assegurar que todas as falhas nos controles de segurana sejam detectadas e resolvidas em tempo hbil. Os processos para resolver
falhas no controle de segurana devem incluir:
Restaurar o controle de segurana
Identificar a causa da falha
Identificar e encaminhar quaisquer problemas de segurana que surgirem durante a falha do controle de segurana
Implementar a minimizao (como controles tcnicos ou de processo) para prevenir que a causa da falha ocorra novamente
Retomar o monitoramento do controle de segurana, talvez com monitoramento aprimorado por um perodo de tempo, para
confirmar que o controle esteja funcionando de maneira efetiva.
3. Revisar alteraes no ambiente (por exemplo, acrscimo de novos sistemas, mudanas nas configuraes de rede ou do sistema) antes
de concluir a alterao e realizar o seguinte:
Determinar o possvel impacto ao escopo do PCI DSS (por exemplo, uma nova regra do firewall que permite a conectividade entre
um sistema no CDE e outro sistema pode trazer redes ou sistemas adicionais ao escopo para o PCI DSS).
Identificar os requisitos do PCI DSS aplicveis aos sistemas e redes afetados pelas alteraes (por exemplo, se um novo sistema
estiver no escopo para o PCI DSS, ser preciso configur-lo de acordo com os padres de configurao de sistema, incluindo FIM,
AV, patches, registros de auditoria, etc. e ser preciso adicion-lo programao trimestral de varredura de vulnerabilidade).
Atualizar o escopo do PCI DSS e implementar controles de segurana conforme o caso
4. Alteraes na estrutura organizacional (por exemplo, aquisio ou fuso de um empresa) devem resultar em reviso formal do impacto ao
escopo e requisitos do PCI DSS.
5. Comunicaes e revises peridicas devem ser realizadas para confirmar que os requisitos do PCI DSS continuam em vigor e que os
funcionrios esto seguindo os processos seguros. Estas revises peridicas devem abranger todas as instalaes e locais, incluindo
pontos de venda, centros de dados, etc. e incluir a reviso dos componentes do sistema (ou amostras dos componentes do sistema), para
garantir que os requisitos do PCI DSS continuem em vigor, por exemplo, os padres de configurao foram aplicados, patches e AV esto

atualizados, logs de auditoria esto sendo revisados e assim por diante. A frequncia das revises peridicas deve ser determinada pela
entidade conforme o tamanho e complexidade de seu ambiente.
Estas revises tambm podem ser usadas para verificar se a evidncia adequada est sendo mantida (por exemplo, logs de auditoria,
relatrios de varredura de vulnerabilidade, revises do firewall, etc.) a fim de auxiliar a preparao da entidade para sua prxima avaliao
de conformidade.
6. Revisar tecnologias do software e hardware pelo menos uma vez ao ano para se certificar se eles continuam com suporte do fornecedor e
se podem atender aos requisitos de segurana da entidade, incluindo o PCI DSS. Se for constatado que as tecnologias no tm mais
suporte do fornecedor ou no possam atender s necessidades de segurana da entidade, esta deve preparar um plano de retificao,
atualizando e incluindo substituio da tecnologia, se necessrio.
Alm das prticas mencionadas acima, as organizaes tambm podem querer considerar a implementao da separao de obrigaes para
suas funes de segurana para que as funes de auditoria e/ou segurana sejam separadas das funes operacionais. Em ambientes em que
um indivduo executa diversas funes (por exemplo, operaes de segurana e administrativas), as obrigaes podem ser atribudas de forma
que nenhum indivduo possua controle total de um processo sem um ponto de verificao independentemente. Por exemplo, as
responsabilidades pela configurao e responsabilidades pela aprovao de alteraes podem ser atribudas a indivduos separados.

Observao: Estas prticas de implementao do PCI DSS nos processos de cenrio de referncia so
fornecidas apenas como recomendao e orientao e elas no substituem ou expandem qualquer
requisito do PCI DSS.

Para os assessores: Amostragem de reas de negcios e componentes do sistema
A amostragem uma opo para que os assessores facilitem o processo de avaliao onde houver grandes nmeros de reas de negcios e/ou
componentes do sistema.
Enquanto aceitvel que um assessor tire amostras das instalaes do negcio/componentes do sistema como parte de sua reviso da
conformidade do PCI DSS de uma entidade, no aceitvel que uma entidade aplique os requisitos do PCI DSS para apenas uma amostra de
seu ambiente (por exemplo, requisitos de varredura trimestral de vulnerabilidade se aplicam a todos os componentes do sistema). Da mesma
forma, no aceitvel que um assessor faa a reviso de apenas uma amostra dos requisitos do PCI DSS para analisar a conformidade.
Aps considerar o escopo e a complexidade gerais do ambiente a ser avaliado, o assessor pode selecionar amostras representativas de reas de
negcios/componentes de sistema independentemente para avaliar a conformidade da entidade com os requisitos do PCI DSS. Essas amostras
devem ser definidas primeiramente para as reas de negcios e, em seguida, para os componentes de sistema em cada rea de negcio
selecionada. As amostras devem ser uma seleo representativa de todos os tipos e locais das reas de negcios, bem como tipos de
componentes de sistema nas reas de negcio selecionadas. As amostras devem ser suficientemente amplas para fornecer ao assessor garantia
de que os controles sero implementados conforme o esperado.
Exemplos de reas de negcios incluem, entre outros, escritrios corporativos, lojas, locais de franquias, reas de processamento, centros de
dados e outros tipos de instalaes em diferentes locais. Os exemplos devem incluir componentes de sistema em cada rea de negcio. Por
exemplo, para cada rea de negcio, inclua uma srie de sistemas operacionais, funes e aplicativos que so aplicveis rea sob anlise.
Como exemplo, o assessor pode definir uma amostra em uma rea de negcios para incluir servidores Sun executando Apache, servidores
Windows executando Oracle, sistemas do mainframe executando aplicativos de processamento de cartes herdados, servidores de transferncia
de dados executando HP-UX e servidores Linux executando MYSQL. Se todos os aplicativos forem executados a partir de um nico SO (por
exemplo, Windows 7 ou Solaris 10), ento, o exemplo tambm dever incluir vrios aplicativos (por exemplo, servidores do banco de dados,
servidores Web, servidores de transferncia de dados).
Ao selecionar exemplos de reas de negcios/componentes de sistema, os avaliadores devem considerar o seguinte:
Se houver segurana, processos e controles operacionais do PCI DSS implementados de forma padro e centralizada que garanta
consistncia e que cada rea de negcio/componente de sistema deva seguir, a amostra poder ser menor do que se no houver
processos/controles padronizados implementados. A amostra dever ser ampla o bastante para fornecer ao assessor garantia razovel de
que todas as reas de negcio/componentes do sistema estejam configurados pelo processo padro. O assessor deve verificar se os
controles centralizados e padronizados esto implementados e funcionando de forma efetiva.
Caso haja mais de um tipo de segurana e ou processo operacional padro implementados (por exemplo, para tipos diferentes de reas
de negcio/componentes do sistema), a amostra deve ser ampla o bastante para incluir reas de negcios/componentes do sistema
seguros com cada tipo de processo.
Caso no haja processos/controles padro implementados e cada rea de negcio/componente do sistema do PCI DSS seja gerenciado
por meio de processos no padronizados, a amostra deve ser maior para o assessor se assegurar de que cada rea de
negcio/componente do sistema tenha implementado os requisitos do PCI DSS apropriadamente.

As amostras de componentes do sistema devem incluir todos os tipos e combinaes em uso. Por exemplo, quando os aplicativos
servem como amostras, a amostra deve incluir todas as verses e plataformas para cada tipo de aplicativo.
Para cada instncia em que a amostragem for usada, o assessor dever:
Registrar o argumento atrs da tcnica de amostragem e do tamanho da amostragem,
Registrar e validar os processos e controles padronizados do PCI DSS usados para determinar o
tamanho da amostra e
Explicar como a amostra adequada e representativa da populao geral.
Os avaliadores devem revalidar o argumento da amostragem para cada avaliao. Se a amostragem for utilizada, diferentes amostras de reas
de negcios e componentes do sistema devem ser selecionadas para cada avaliao.

Controles de compensao
Anualmente, quaisquer controles de compensao devem ser documentados, revisados e validados pelo assessor e includos no envio do
Relatrio sobre conformidade, de acordo com o Apndice B: Controles de compensao e Apndice C: Planilha dos controles de compensao.
Para cada um dos controles de compensao, a Planilha dos controles de compensao (Apndice C) deve ser preenchida. Alm disso, os
resultados dos controles de compensao devem ser registrados no ROC na seo de requisitos do PCI DSS correspondente.
Para obter mais detalhes sobre "controles de compensao", consulte os Apndices B e C mencionados acima.

Consulte tambm:
Apndice D: Segmentao
e amostragem de reas de
negcios/componentes do
sistema

Instrues e contedo para o relatrio sobre conformidade
As instrues e o contedo do Relatrio de conformidade (ROC) agora so informados no Modelo de relatrio do PCI DSS.
O Modelo de relatrio ROC do PCI DSS deve ser usado como modelo para gerar o Relatrio de conformidade. A entidade avaliada deve seguir
os requisitos de informe respectivos de cada bandeira de pagamento para assegurar que cada bandeira de pagamento reconhea o status de
conformidade da entidade. Entre em contato com cada bandeira de pagamento ou adquirente para definir os requisitos e instrues de relatrio.

Processo de avaliao do PCI DSS
1. Verifique o escopo da avaliao do PCI DSS.
2. Realize a avaliao do PCI DSS do ambiente, seguindo os procedimentos de teste para cada requisito.
3. Se necessrio, realize retificaes para qualquer item inadequado.
4. Conclua o relatrio aplicvel para a avaliao (ou seja, Questionrio deautoavaliao (SAQ) ou Relatrio de conformidade (ROC),
incluindo a documentao de todos os controles compensatrios, de acordo com as instrues e orientaes aplicveis do PCI.
5. Preencha por completo o atestado de conformidade referente aos prestadores de servios ou comerciantes, conforme aplicvel. Os
atestados de conformidade esto disponveis no site do PCI SSC.
6. Envie o SAQ ou ROC e o atestado de conformidade, junto com qualquer outra documentao solicitada, como relatrios de varredura de
ASV, ao adquirente (para comerciantes) ou bandeira de pagamento ou outro solicitante (para prestadores de servios).

Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana
As informaes a seguir definem os cabealhos das colunas para os requisitos do PCI DSS e procedimentos da avaliao de segurana:
Requisitos do PCI DSS Esta coluna define os requisitos do padro de segurana dos dados; a conformidade do PCI DSS validada
de acordo com esses requisitos.
Procedimentos de teste Esta coluna exibe os processos a serem seguidos pelo assessor para validar se os requisitos do PCI DSS
tm sido atendidos e se esto "vigentes"
Orientao Esta coluna descreve a inteno ou o objetivo de segurana por trs de cada um dos requisitos do PCI DSS. Esta coluna
contm apenas orientao e tem o objetivo de auxiliar a compreender o porqu de cada requisito. A orientao nesta coluna no substitui
ou expande os Requisitos do PCI DSS e Procedimentos de teste.
Observao: Os requisitos do PCI DSS no so considerados adequados se os controles ainda no estiverem implementados ou programados
para estarem concludos em uma data futura. Depois que qualquer item em aberto ou inadequado for reportado entidade, o assessor far uma
reavaliao para validar se a soluo foi concluda e se todos os requisitos foram atendidos.
Consulte os seguintes recursos (disponveis no site do PCI SSC) para documentar a avaliao do PCI DSS:
Para obter instrues sobre a concluso de relatrios de conformidade (ROC), consulte o Modelo de relatrio ROC do PCI DSS.
Para obter instrues sobre a concluso de questionrios de autoavaliao (SAQ), consulte as Instrues e orientaes SAQ do PCI
DSS.
Para obter instrues sobre o envio dos relatrios de validao de conformidade do PCI DSS, consulte os atestados de conformidade do
PCI DSS.

Construir e manter a segurana de rede e sistemas
Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do portador do carto
Firewalls so dispositivos do computador que controlam o trfego do computador permitido entre a rede de uma empresa (interna) e redes no
confiveis (externa), assim como o trfego dentro e fora de muitas reas confidenciais na rede confivel interna de uma empresa. O ambiente de
dados do portador do carto um exemplo de uma rea mais sensvel dentro da rede confivel de uma empresa.
Um firewall examina todo o trfego da rede e bloqueia aquelas transmisses que no atendem aos critrios de segurana especficos.
Todos os sistemas devem ser protegidos do acesso no autorizado de redes no confiveis, seja acessando o sistema por meio da internet como
e-commerce, acesso internet atravs dos navegadores na rea de trabalho por parte dos funcionrios, acesso via e-mail dos funcionrios,
conexo dedicada como conexes entre negcios, por meio de redes sem fio ou de outras fontes. Com frequncia, trajetos aparentemente
insignificantes que direcionam ou partem de redes no confiveis podem fornecer caminhos no protegidos aos sistemas principais. Os firewalls
so um mecanismo de proteo essencial para qualquer rede de computador.
Outros componentes do sistema podem oferecer a funcionalidade de firewall, contanto que atendam aos requisitos mnimos para firewalls,
conforme definido no Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do portador do carto para
oferecer a funcionalidade do firewall, esses dispositivos devero ser includos no escopo e na avaliao do Requisito 1.
REQUISITOS DO PCI DSS PROCEDIMENTOS DE TESTE ORIENTAO
1.1 Defina e implemente os padres de
configurao do firewall e do roteador
que incluam o seguinte:
1.1 Inspecione os padres de configurao do firewall e do
roteador, alm de outras documentaes especificadas abaixo
e verifique se os padres esto concludos e implementados
conforme segue:
Firewalls e roteadores so os principais
componentes da arquitetura que controlam a
entrada e a sada da rede. Esses dispositivos so
software ou hardware que bloqueiam acesso
indesejado e gerenciam acesso autorizado de e
para a rede.
Os procedimentos e padres de configurao
ajudaro a garantir que a primeira linha de defesa
da organizao na proteo de seus dados
continue forte.
1.1.1 Um processo formal para
aprovar e testar todas as conexes de
rede e alteraes s configuraes do
firewall e do roteador
1.1.1 Examine os procedimentos documentados para saber
se h um processo formal para testar e aprovar todas as:
Conexes de rede e
Alteraes nas configuraes do roteador e do firewall
Um processo documentado e implementado para
aprovar e testar todas as conexes e alteraes
nos firewalls e roteadores ajudar a evitar
problemas de segurana causados pela m
configurao da rede, do roteador ou do firewall.
Sem a aprovao formal e teste das alteraes,
os registros das alteraes podem no ser
atualizados, o que pode levar inconsistncia
entre a documentao de rede e a configurao
1.1.1.bPara obter uma amostra de conexes de rede,
converse com o funcionrio responsvel e examine registros
para verificar se elas foram aprovadas e testadas.

em si.
1.1.1.c Identifique uma amostra de alteraes reais realizadas
nas configuraes do roteador e do firewall, compare com os
registros da alterao e converse com o funcionrio
responsvel para verificar se as alteraes foram aprovadas e
testadas.

1.1.2 Diagrama atual da rede que
identifica todas as conexes entre o
ambiente dos dados do portador do
carto e outras redes, incluindo
qualquer rede sem fio
1.1.2.a Analise o(s) diagrama(s) e observe as configuraes
de rede para saber se existe um diagrama de rede e se ele
registra todas as conexes com relao aos dados do
portador do carto, incluindo quaisquer redes sem fio.
Os diagramas de rede descrevem como as redes
so configuradas e identificam a localizao de
todos os dispositivos de rede.
Sem os diagramas da rede atual, os dispositivos
podem ser ignorados e sem querer deixados de
fora dos controles de segurana implementados
para PCI DSS e, assim, vulnerveis ao
comprometimento.
1.1.2.b Converse com o funcionrio responsvel para verificar
se o diagrama mantido atualizado.
1.1.3 Diagrama atual que mostra todos
os fluxos de dados do portador do
carto pelos sistemas e redes
1.1.3 Analise o diagrama do fluxo de dados e converse com o
funcionrio para verificar se o diagrama:
Mostra todos os fluxos de dados do portador do carto
pelos sistemas e redes.
mantido atualizado conforme necessrio em relao s
alteraes no ambiente.
Os diagramas de fluxo de dados do portador do
carto identificam a localizao de todos os
dados do portador do carto que so
armazenados, processados ou transmitidos
dentro da rede.
Os diagramas de fluxo de dados do portador do
carto e de rede ajudam uma organizao a
compreender e acompanhar o escopo de seu
ambiente, mostrando como os dados do portador
do carto passam pelas redes e entre os
dispositivos e sistemas individuais.
1.1.4 Requisitos para um firewall em
cada conexo da internet e entre
qualquer zona desmilitarizada (DMZ) e
a zona de rede interna
1.1.4.a Analise os padres de configurao do firewall e
verifique se eles incluem requisitos para um firewall em cada
conexo da internet e entre qualquer DMZ e a zona de rede
interna.
Usar um firewall em todas as conexes de
internet que entram e saem da rede e entre
qualquer DMZ e a rede interna permite que a
organizao monitore e controle o acesso e
minimize as chances de um indivduo mal-
intencionado obter acesso rede interna por meio
de uma conexo no protegida.

1.1.4.b Verifique se o diagrama da rede atual est de acordo
com os padres de configurao do firewall.
1.1.4.c Observe as configuraes de rede para verificar se um
firewall est implementado em cada conexo da internet e
entre qualquer zona desmilitarizada (DMZ) e a zona de rede
interna, conforme os padres de configurao registrados e

os diagramas de rede.
1.1.5Descrio de grupos, funes e
responsabilidades quanto ao
gerenciamento dos componentes da
rede
1.1.5.aVerifique se os padres de configurao do firewall e
do roteador incluem uma descrio dos grupos, funes e
responsabilidades quanto ao gerenciamento dos
componentes da rede.
Essa descrio de funes e a atribuio das
responsabilidades garante que os funcionrios
estejam cientes de quem responsvel pela
segurana de todos os componentes da rede e
que os responsveis por gerenciar os
componentes estejam cientes de suas
responsabilidades. Se as funes e
responsabilidades no forem atribudos
formalmente, os dispositivos podem ficar sem
gerenciamento.
1.1.5.bConverse com o funcionrio responsvel pelo
gerenciamento dos componentes da rede para confirmar se
as funes e responsabilidades esto atribudos conforme o
que est registrado.
1.1.6 Documentao e justificativa
comercial para o uso de todos os
servios, protocolos e portas
permitidas, incluindo a documentao
dos recursos de segurana
implementados para os protocolos
considerados no seguros.
Exemplos de servios, protocolos ou
portas no seguros incluem, entre
outros, FTP, Telnet, POP3, IMAP e
SNMP v1 e v2.
1.1.6.a Verifique se os padres de configurao do firewall e
do roteador incluem uma lista documentada dos servios,
protocolos e portas, incluindo a justificativa do negcio, por
exemplo, protocolos HTTP (Hypertext Transfer Protocol), SSL
(Secure Sockets Layer), SSH (Secure Shell) e VPN (Virtual
Private Network).
Muitas vezes ocorrem comprometimentos
decorrentes de portas e servios no utilizados ou
no seguros, visto que frequente eles
possurem vulnerabilidades conhecidas e muitas
organizaes no aplicam patches nas
vulnerabilidades para servios, protocolos e
portas que eles no utilizam (embora as
vulnerabilidades ainda estejam presentes).
Definindo e documentando claramente quais
portas, servios e portas so necessrios para a
empresa, as organizaes podem garantir que
todos os outros servios, protocolos e portas
sejam desabilitados ou removidos.
Se portas, servios e protocolos no seguros
forem necessrios para a empresa, o risco
apresentado pelo uso desses protocolos deve ser
claramente entendido e aceito pela organizao,
o uso do protocolo deve ser justificado e os
recursos de segurana que permitem que esses
protocolos sejam usados com segurana devero
ser documentados e implementados. Se esses
servios, portas e protocolos no seguros no
forem necessrios para a empresa, eles devero
ser desativados ou removidos.
1.1.6.b Identifique portas, servios e protocolos no seguros
permitidos e verifique se os recursos de segurana esto
documentados para cada servio.
1.1.6.c Analise as configuraes do roteador e do firewall
para verificar se os recursos de segurana documentados
esto implementados para cada porta, servio e protocolo no
seguros.

1.1.7 Requisito para analisar os
conjuntos de regras do firewall e do
roteador pelo menos a cada seis
meses
1.1.7.a Verifique se os padres de configurao do firewall e
do roteador exigem a anlise dos conjuntos de regras do
roteador e do firewall pelo menos a cada seis meses.
Essa anlise d organizao a oportunidade de,
pelo menos a cada seis meses, limpar todas as
regras desnecessrias, obsoletas ou incorretas e
garantir que todos os conjuntos de regras
permitam apenas servios e portas autorizados
que correspondam s justificativas registradas de
negcios.
As organizaes que possuem alto volume de
alteraes nos conjuntos de regras do roteador e
do firewall podem querer realizar as revises com
mais frequncia a fim de garantir que os
conjuntos de regras continuem a atender as
necessidades da empresa.
1.1.7.b Analise a documentao referente s revises do
conjunto de regras e converse com o funcionrios para
verificar se os conjuntos de regras so revisados pelo menos
a cada seis meses.
1.2 Elabore configuraes de firewall e
roteador que restrinjam as conexes
entre redes no confiveis e quaisquer
componentes do sistema no ambiente
de dados do portador do carto.
Observao: Uma rede no confivel
qualquer rede que seja externa s
redes que pertencem entidade em
anlise e/ou que esteja alm da
capacidade da entidade de controlar ou
gerenciar.
1.2 Examine as configuraes do firewall e do roteador para
verificar se as conexes esto restritas entre as redes no
confiveis e os componentes de sistema no ambiente de dados
do portador do carto:
essencial instalar proteo de rede entre a rede
interna e confivel e qualquer rede no confivel
que seja externa e/ou fique fora da capacidade de
controle ou gerenciamento da entidade. A falha
em implementar essa medida de forma correta
resulta na vulnerabilidade da entidade ao acesso
no autorizado de indivduos ou softwares mal-
intencionados.
Para que a funcionalidade do firewall seja eficaz,
ele deve ser configurado corretamente para
controlar e/ou limitar o trfego dentro e fora da
rede da entidade.
1.2.1 Restrinja o trfego de entrada e
sada ao que necessrio ao
ambiente de dados do portador do
carto e rejeite especificadamente
todos os outros trfegos.
1.2.1.a Analise os padres de configurao do roteador e do
firewall para verificar se eles identificam o trfego de entrada
e sada necessrio para o ambiente de dados do portador do
carto.
Esse requisito destina-se a evitar que indivduos
mal-intencionados acessem a rede da entidade
por meio de endereos IP no autorizados ou
usem servios, protocolos ou portas de forma no
autorizada (por exemplo, enviando dados obtidos
dentro da sua rede para um servidor no
confivel).
Implementar uma regra que rejeite todos os
trfegos de entrada e sada no necessrios
ajuda a evitar violaes acidentais que permitam
que trfego potencialmente prejudicial entre ou
saia.
1.2.1.bAnalise as configuraes do roteador e do firewall para
verificar se o trfego de entrada e sada est limitado ao que
necessrio para o ambiente de dados do portador do carto.
1.2.1.c Analise as configuraes do roteador e do firewall
para verificar se todos os outros trfegos de entrada e sada
so recusados de forma especfica, por exemplo, ao usar a
opo explcita "recusar todos" ou uma recusa implcita aps

a declarao de permisso.
1.2.2 Proteja e sincronize os arquivos
de configurao do roteador.
1.2.2.a Analise os arquivos de configurao do roteador para
verificar se eles esto seguros em relao ao acesso no
autorizado.
Enquanto os arquivos de configurao do
roteador executados (ou ativos) incluem as
configuraes seguras e atuais, os arquivos de
inicializao (que so usados quando os
roteadores so reiniciados ou ligados) devem ser
atualizados com as mesmas configuraes
seguras para garantir que estas configuraes
sejam aplicadas quando a configurao de
inicializao executada.
Por serem executados apenas de vez em
quando, os arquivos de configurao de
inicializao so frequentemente esquecidos e
no so atualizados. Quando o roteador
reinicializar e carregar uma configurao de
inicializao que no tenha sido atualizada com
as mesmas configuraes seguras que a
configurao de execuo, isso pode resultar em
regras mais fracas que permitam que indivduos
mal-intencionados entrem na rede.
1.2.2.b Analise as configuraes do roteador para verificar se
eles esto sincronizados, por exemplo, a configurao
executada (ou ativa) corresponde configurao de
inicializao (usada quando as mquinas so ligadas).
1.2.3 Instale firewalls de permetro
entre todas as redes sem fio e o
carto e configure esses firewalls para
recusar ou, se o trfego for necessrio
para fins comerciais, permitir apenas
trfego autorizado entre o ambiente
sem fio e o ambiente de dados do
portador do carto.
1.2.3.a Analise as configuraes do firewall e do roteador
para verificar se h firewalls de permetro instalados entre
todas as redes sem fio e o ambiente de dados do portador do
carto.
A implementao conhecida (ou desconhecida) e
a explorao da tecnologia sem fio dentro de uma
rede um caminho comum para indivduos mal-
intencionados ganharem acesso rede e aos
dados do portador do carto. Se um dispositivo
sem fio ou uma rede forem instalados sem o
conhecimento da entidade, um indivduo mal-
intencionado pode fcil e invisivelmenteentrar
na rede. Se os firewalls no restringirem o acesso
das redes sem fio no CDE, indivduos mal-
intencionados que tiverem acesso no autorizado
rede sem fio podero se conectar facilmente ao
CDE e comprometer as informaes da conta.
Devero ser instalados firewalls entre todas as
redes sem fio e o CDE, independentemente da
finalidade do ambiente com o qual a rede sem fio
estiver conectada. Isto pode incluir, entre outros,
redes corporativas, revendedores, redes de
1.2.3.b Verifique se os firewalls recusam ou, se o trfego for
necessrio para fins comerciais, permitem apenas trfego
autorizado entre o ambiente sem fio e o ambiente de dados
do portador do carto.

acesso ao visitante, ambientes de
armazenamento, etc.
1.3 Proba o acesso pblico direto entre
a internet e qualquer componente do
sistema no ambiente de dados do
portador do carto.
1.3 Analise as configuraes do firewall e do roteador
(incluindo, entre outros, roteador de suspenso na internet, o
roteador DMZ e o firewall, o segmento DMZ do portador do
carto, o roteador de permetro e o segmento interno da rede
do portador do carto) e realizar o que segue para determinar
que no haja acesso direto entre a internet e os componentes
do sistema no segmento interno da rede de dados do portador
do carto.
O objetivo do firewall gerenciar e controlar todas
as conexes entre os sistemas pblicos e
internos, especialmente aqueles que armazenam,
processam ou transmitem os dados do portador
do carto. Se for permitido o acesso direto entre
sistemas pblicos e o CDE, as protees
oferecidas pelo firewall sero ignoradas e os
componentes do sistema que armazenam os
dados do portador do carto podero ser
comprometidos.
1.3.1 Implemente uma DMZ para
limitar o trfego somente para
componentes do sistema que oferece
servios, protocolos e portas
acessveis publicamente.
1.3.1 Analise as configuraes do firewall e do roteador para
verificar se uma DMZ foi implementada para limitar o trfego
somente para componentes do sistema que oferea servios,
protocolos e portas acessveis publicamente.
O DMZ a parte da rede responsvel pelo
gerenciamento das conexes entre a internet (ou
redes no confiveis) e os servios que uma
empresa precisa disponibilizar para o pblico
(como um servidor Web).
Este recurso ser utilizado para evitar que
indivduos mal-intencionados acessem a rede
interna da empresa pela internet ou por meio de
servios, protocolos ou portas de forma no
autorizada.
1.3.2 Limite o trfego de entrada da
internet a endereos IP na DMZ.
verificar se o trfego de entrada da internet est limitado a
endereos IP na DMZ.
1.3.3No permita a entrada ou sada
de nenhuma rota direta com relao
ao trfego entre a internet e o
carto.
1.3.3Analise as configuraes do firewall e do roteador para
verificar se a entrada ou sada de nenhuma rota direta com
relao ao trfego entre a internet e o ambiente de dados do
portador do carto no esto autorizadas.
A anlise de todas as conexes de entrada e
sada permite a inspeo e restrio de trfego
com base na fonte e/ou endereo de destino, bem
como inspeo e bloqueio de contedo no
desejado, evitando assim o acesso no filtrado
entre ambientes confiveis e no confiveis. Isto
ajudar a evitar, por exemplo, que indivduos mal-
intencionados enviem dados obtidos na rede para
um servidor externo no confivel em uma rede
no confivel.

1.3.4 Implemente medidas contra
falsificao para detectar e impedir
que endereos IP de fonte falsificada
entrem na rede.
(Por exemplo, bloquear trfego
originado da internet com um
endereo de fonte interna).
verificar se as medidas contra falsificao esto
implementadas, por exemplo, os endereos internos no
conseguem passar da internet para a DMZ.
Normalmente, um pacote contm o endereo IP
do computador que originalmente o enviou para
que os outros computadores da rede saibam de
onde vem o pacote. Indivduos mal-intencionados
tentaro falsificar (ou copiar) o endereo de envio
do IP para que o sistema alvo acredite que o
pacote seja de uma fonte confivel.
Filtrar pacotes que entram na rede ajuda, entre
outras coisas, a garantir que os pacotes no
sofram falsificao, parecendo que vm da
prpria rede interna da organizao.
1.3.5No permita o trfego de sada
no autorizado do ambiente de dados
do portador do carto para a internet.
verificar se o trfego de sada do ambiente de dados do
portador do carto para a internet est explicitamente
autorizado.
Todo o trfego que sair do ambiente de dados do
portador do carto dever ser avaliado para
garantir que esteja de acordo com as regras
autorizadas preestabelecidas. As conexes
devero ser inspecionadas para restringir o
trfego de forma a permitir apenas as
comunicaes autorizadas (por exemplo
restringindo portas/endereos de origem/destino
ou bloqueando o contedo).
1.3.6 Implemente inspeo com
status, tambm conhecida como
filtragem de pacote dinmico. (Ou
seja, somente conexes
"estabelecidas" so permitidas na
rede.)
verificar se o firewall desempenha a inspeo com status
(filtragem de pacote dinmica). (Somente conexes
estabelecidas devem ser permitidas a entrar e somente se
estiverem associadas a alguma sesso previamente
estabelecida.)
Um firewall que executa inspeo de pacotes com
status mantm o status(ou estado) de cada
conexo atravs do firewall. Mantendo o "status",
o firewall sabe se uma resposta aparente a uma
conexo anterior realmente uma resposta vlida
e autorizada (j que ele preserva cada status de
conexo) ou se trfego mal-intencionado
tentando enganar o firewall para que este permita
a conexo.

1.3.7 Implemente os componentes do
sistema que armazenam dados do
portador do carto (como banco de
dados) em uma zona de rede interna,
separada da DMZ e de outras redes
no confiveis.
verificar se os componentes do sistema que armazenam
dados do portador do carto esto em uma zona de rede
interna, separada da DMZ e de outras redes no confiveis.
Se os dados do portador do carto estiverem
localizados dentro da DMZ, o acesso a essas
informaes ser mais fcil para um invasor
externo, pois h poucas camadas a serem
penetradas. Proteger os componentes do sistema
que armazenam os dados do portador do carto
em uma zona de rede interna separada da DMZ e
de outras redes no confiveis com um firewall
pode evitar que um trfego de rede no
autorizado alcance o componente do sistema.
Observao: Este requisito no se aplica ao
armazenamento temporrio dos dados do
portador do carto em memria voltil.
1.3.8 No divulgue endereos IP
privados e informaes de roteamento
a partes no autorizadas.
Observao: Os mtodos para ocultar
o endereo IP podem incluir, entre
outros:
Converso de endereos de rede
(NAT)
Implementao dos servidores
contendo dados do portador do
carto atrs dos servidores de
proxy/firewalls,
Remoo ou filtragem das
propagandas de rota para redes
privadas que empregam
endereamento registrado,
Uso interno do espao de endereo
RFC1918 em vez de endereo
registrado.
1.3.8.a Analise as configuraes do firewall e do roteador
para verificar se os mtodos esto implementados para evitar
a divulgao de endereos IP privados e informaes de
roteamento das redes internas para a internet.
Restringir a divulgao de endereos IP internos
ou privados essencial para evitar que os
hackers "descubram" os endereos IP da rede
interna e utilizem essas informaes para acessar
a rede.
Os mtodos usados para atender inteno
deste requisito podem variar de acordo com a
tecnologia de rede especfica utilizada. Por
exemplo, os controles utilizados para atender a
estes requisitos em redes IPv4 podero ser
diferentes daqueles utilizados em redes IPv6.

1.3.8.b Questione os funcionrios e analise a documentao
para verificar se qualquer divulgao de endereos IP
privados e informaes de roteamento a entidades externas
est autorizada.

1.4Instale o software de firewall pessoal
em quaisquer dispositivos mveis e/ou
de propriedade do funcionrio com
conectividade internet quando
estiverem fora da rede (por exemplo,
laptops usados pelos funcionrios) e
que tambm so usados para acessar a
rede. As configuraes do firewall
incluem:
Os ajustes especficos de
configurao so definidos pelo
software do firewall pessoal.
O software do firewall pessoal est
funcionando ativamente.
O software do firewall pessoal no
pode ser alterado pelos usurios dos
dispositivos mveis e/ou de
propriedade do funcionrio.
1.4.aAnalise as polticas e padres de configurao para
verificar:
O software de firewall pessoal necessrio para todos os
dispositivos mveis e/ou de propriedade do funcionrio com
conectividade internet (por exemplo, laptops usados pelos
funcionrios) quando esto fora da rede e que tambm so
usados para acessar a rede.
Os ajustes especficos de configurao so definidos pelo
software do firewall pessoal.
O software do firewall pessoal est configurado para
funcionar ativamente.
O software de firewall pessoal est configurado para no
ser alterado pelos usurios de dispositivos mveis e/ou de
propriedade do funcionrio.
Os dispositivos portteis de computao que tm
permisso para conectar-se internet fora do
firewall corporativo so mais vulnerveis s
ameaas baseadas na internet. O uso de um
firewall pessoal ajuda a proteger os dispositivos
de invases via internet, o qual pode usar o
dispositivo para obter acesso aos dados e
sistemas da organizao, uma vez que o
dispositivo reconectado rede.
Os ajustes especficos das configuraes do
firewall so determinados pela organizao.
Observao: O objetivo deste requisito se aplica
a computadores de propriedade do funcionrio e
da empresa. Os sistemas que no podem ser
gerenciados pelas polticas empresariais
introduzem fraquezas ao permetro e oferecem
oportunidades a pessoas mal-intencionadas.
Permitir que sistemas no confiveis se conectem
rede da organizao pode resultar em acesso
garantido aos invasores e outros usurios mal-
intencionados.
1.4.b Inspecione uma amostra dos dispositivos mveis e/ou de
propriedade do funcionrio para verificar se:
O software de firewall pessoal instalado e configurado de
acordo com os ajustes de configurao especficos da
organizao.
O software do firewall pessoal est funcionando ativamente.
O software do firewall pessoal no pode ser alterado pelos
usurios dos dispositivos mveis e/ou de propriedade do
funcionrio.
1.5 Certifique-se de que as polticas de
segurana e procedimentos
operacionais do gerenciamento dos
firewalls estejam documentados, em uso
e conhecidos por todas as partes
envolvidas.
1.5 Analise a documentao e questione os funcionrios para
verificar se as polticas de segurana e procedimentos
operacionais do gerenciamento dos firewalls esto:
Documentados,
Em uso, e
Conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir
as polticas de segurana e os procedimentos
operacionais para garantir que os firewalls e
roteadores sejam continuamente gerenciados a
fim de evitar o acesso no autorizado rede.

Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de
segurana
Indivduos mal-intencionados (dentro e fora de uma empresa) com frequncia usam senhas padro do fornecedor e outras configuraes padro
do fornecedor para comprometer os sistemas. Essas senhas e configuraes so bastante conhecidas pelas comunidades de hackers e
facilmente determinadas por meio de informaes pblicas.

2.1 Sempre altere os padres
disponibilizados pelo fornecedor e
remova ou desabilite contas padro
desnecessrias antes de instalar um
sistema na rede.
Isto se aplica a TODAS as senhas
padro, incluindo, entre outros, as
usadas pelos sistemas operacionais,
software que oferece servios de
segurana, aplicativos e contas de
sistema, terminais de pontos de venda
(POS), strings de comunidade SNMP
(Simple Network Management Protocol),
etc.).
2.1.a Escolha uma amostra dos componentes do sistema e
tente acessar (com a ajuda do administrador do sistema) os
dispositivos e aplicativos usando as contas e senhas padro
disponibilizadas pelo fornecedor, para verificar se TODAS as
senhas padro (incluindo as que esto nos sistemas
operacionais, software que oferece servios de segurana,
aplicativos e contas de sistema, terminais POS e strings de
comunidade SNMP (Simple Network Management Protocol))
foram alteradas. (Use os manuais do fornecedor e as fontes na
internet para localizar as contas/senhas disponibilizadas pelo
fornecedor.)
Indivduos mal-intencionados (dentro e fora de
uma empresa) com frequncia usam as
configuraes, nomes de conta e senhas padro
do fornecedor para comprometer o software do
sistema operacional, aplicativos e os sistemas
nos quais eles esto instalados. Por estas
configuraes padro serem frequentemente
publicadas e bem conhecidas nas comunidades
de hackers, alterar estas configuraes deixar
os sistemas menos vulnerveis a invases.
Mesmo se uma conta padro no tem o objetivo
de ser usada, alterar a senha padro para uma
senha forte e exclusiva e ento desabilitar a conta
evitar que um indivduo mal-intencionado
reabilite a conta e obtenha acesso com a senha
padro.
2.1.b Para obter um exemplo dos componentes do sistema,
verifique se todas as contas padro desnecessrias (incluindo
contas usadas pelos sistemas operacionais, software de
segurana, aplicativos, sistemas, terminais POS, SNMP, etc.)
foram removidas ou desabilitadas.
2.1.c Questione os funcionrios e analise a documentao de
suporte para verificar se:
Todas as senhas padro (incluindo senhas padro em
sistemas operacionais, software que oferece servios de
segurana, aplicativos e contas do sistema, terminais POS,
strings de comunidade SNMP (Simple Network
Management Protocol), etc.)) so alteradas antes de um
sistema ser instalado na rede.
Contas padro desnecessrias (incluindo contas usadas
pelos sistemas operacionais, software de segurana,
aplicativos, sistemas, terminais POS, SNMP, etc.) so
removidas ou desabilitadas antes de um sistema ser
instalado na rede.

2.1.1 Em ambientes sem fio
conectados ao ambiente de dados do
portador do carto ou que transmitam
dados do portador do carto, altere
TODOS os padres do fornecedor sem
fio na instalao, incluindo, entre
outros, chaves de criptografia sem fio
padro, senhas e strings de
comunidades de SNMP.
2.1.1.a Questione os funcionrios responsveis e analise a
documentao de suporte para verificar se:
As chaves de criptografia foram modificadas a partir do
padro na instalao
As chaves de criptografia padro so modificadas
sempre que um funcionrio que conhece as chaves sai
da empresa ou troca de cargo.
Se as redes sem fio no forem implementadas
com configuraes de segurana suficientes
(incluindo a alterao das configuraes padro),
os sniffers da rede sem fio conseguem espreitar o
trfego, capturar dados e senhas e entrar e
invadir a sua rede com facilidade.
Alm disso, o protocolo de troca de chaves para
verses mais antigas da criptografia 802.11x
(Wired Equivalent Privacy ou WEP) foi quebrado
e pode tornar a criptografia intil. O firmware dos
dispositivos deve estar atualizado para suportar
protocolos mais seguros.
2.1.1.b Questione os funcionrios e consulte a as polticas e
procedimentos para verificar se:
As strings de comunidades de SNMP padro precisam
ser modificadas na instalao.
As senhas/frases padro nos pontos de acesso precisam
ser modificadas na instalao.
2.1.1.c Consulte a documentao do fornecedor e conecte-se
aos dispositivos sem fio, com a ajuda do administrador do
sistema, para verificar se:
As strings de comunidades de SNMP padro no so
utilizadas.
As senhas padro dos pontos de acesso no so
utilizadas.
2.1.1.d Consulte a documentao do fornecedor e observe os
ajustes da configurao sem fio para verificar se o firmware
nos dispositivos sem fio foi atualizado para ser compatvel
com a criptografia forte para:
Autenticao em redes sem fio
Transmisso em redes sem fio.
2.1.1.e Analise a documentao do fornecedor e observe os
ajustes da configurao sem fio para verificar se outros
padres sem fio do fornecedor ligados segurana foram
alterados, se aplicvel.

2.2 Desenvolva padres de configurao
para todos os componentes do sistema.
Certifique-se de que esses padres
abrangem todas as vulnerabilidades de
segurana conhecidas e esto em
conformidade com os padres de
fortalecimento do sistema aceitos pelo
setor.
As fontes dos padres de proteo do
sistema aceitos pelo setor podem incluir,
entre outros:
Center for Internet Security (CIS)
International Organization for
Standardization (ISO)
Instituto SysAdmin Audit Network
Security (SANS)
National Institute of Standards and
Technology (NIST).
2.2.a Analise os padres de configurao do sistema da
organizao para todos os tipos de componentes do sistema e
verifique se os padres de configurao do sistema so
consistentes com os padres de proteo aceitos pelo setor.
Existem pontos fracos conhecidos em vrios
sistemas operacionais, bancos de dados e
aplicativos empresariais, alm disso existem
tambm formas conhecidas de configurar esses
sistemas para corrigir as vulnerabilidades de
segurana. Para ajudar quem no especialista
em segurana, as organizaes de segurana
criaram recomendaes e orientaes para
proteo do sistema que aconselham como
corrigir esses pontos fracos.
Exemplos de fontes para orientao sobre
padres de configurao incluem, entre outros:
www.nist.gov, www.sans.org, www.cisecurity.org,
www.iso.org e fornecedores do produto.
Os padres de configurao do sistema devero
ser mantidos atualizados para garantir que as
deficincias recentemente identificadas sejam
corrigidas antes de o sistema ser instalado na
rede.
2.2.b Analise as polticas e questione os funcionrios para
verificar se os padres de configurao do sistema esto
atualizados conforme novos problemas de vulnerabilidade so
identificados, conforme definido no Requisito 6.1.
2.2.c Analise as polticas e questione os funcionrios para
verificar se os padres de configurao do sistema so
aplicados quando novos sistemas so configurados e
considerados adequados antes de o sistema ser instalado na
rede.
2.2.d Verifique se os padres de configurao do sistema
incluem os seguintes procedimentos para todos os tipos de
componentes do sistema:
Alterao de todos os padres informados pelo fornecedor
e eliminao de contas padro desnecessrias
Implementao de apenas uma funo principal por
servidor para evitar funes que exigem diferentes nveis
de segurana coexistindo no mesmo servidor
Habilitar apenas servios, protocolos, daemons, etc.
necessrios, conforme exigido para a funo do sistema
Implantar recursos de segurana adicionais para todos os
servios, protocolos ou daemons exigidos que forem
considerados no seguros
Configurar os parmetros de segurana do sistema para
impedir o uso incorreto
Remover todas as funcionalidades desnecessrias, como
scripts, drivers, recursos, subsistemas, sistemas de arquivo
e servidores Web desnecessrios.

2.2.1Implemente somente uma funo
principal por servidor para evitar
funes que exigem diferentes nveis
de segurana coexistindo no mesmo
servidor. (Por exemplo, servidores
Web, servidores do banco de dados e
DNS devem ser implementados em
servidores separados.)
Observao: Onde tecnologias de
virtualizao estiverem em uso,
implemente somente uma funo
principal por componente do sistema
virtual.
2.2.1.a Selecione uma amostra dos componentes do sistema
e inspecione as configuraes do sistema para verificar se
somente uma funo principal est implementada por
servidor.
Se funes do servidor que precisam de
diferentes nveis de segurana estiverem
localizadas no mesmo servidor, o nvel de
segurana das funes com maior necessidade
de segurana pode ser reduzido devido
presena das funes de menor segurana. Alm
disso, as funes do servidor com menor nvel de
segurana podem apresentar falhas da
segurana para outras funes no mesmo
servidor. Considerando as necessidades de
segurana de diferentes funes do servidor
como parte dos padres de configurao do
sistema e processos relacionados, as
organizaes podem garantir que as funes que
exigem diferentes nveis de segurana no
coexistam no mesmo servidor.
2.2.1.bSe forem usadas tecnologias de virtualizao,
inspecione as configuraes do sistema para verificar se
somente uma funo principal est implementada por
componente ou dispositivo do sistema virtual.
2.2.2 Habilite somente servios,
protocolos, daemons, etc., necessrios
para a funo do sistema.
e inspecione os servios, daemons e protocolos do sistema
ativado para verificar se apenas os servios ou protocolos
necessrios esto habilitados.
Conforme informado no item 1.1.6, existem
muitos protocolos de que uma empresa pode
precisar (ou estarem ativados por padro) que
normalmente so usados por indivduos mal-
intencionados para comprometer uma rede.
Incluir este requisito como parte dos padres de
configurao da empresa e dos processos
relacionados garante que apenas os servios e
protocolos necessrios sejam habilitados.
2.2.2.b Identifique qualquer servio, daemons ou protocolos
no seguros que estejam habilitados e questione os
funcionrios para verificar se eles tm justificativa conforme
os padres de configurao documentados.
2.2.3 Implemente recursos de
segurana adicionais para quaisquer
servios, protocolos ou daemons
considerados no seguros, por
exemplo, utilize tecnologias seguras,
como SSH, S-FTP, SSL ou IPSec VPN
para proteger servios no seguros
como o NetBIOS, file-sharing, Telnet,
FTP, etc.
2.2.3Inspecione os ajustes de configurao para verificar se
os recursos de segurana esto documentados e
implementados para todos os servios, daemons ou
protocolos no seguros.
Habilitar recursos de segurana antes que novos
servidores sejam implantados evitar que os
servidores sejam instalados no ambiente com
configuraes no seguras.
Garantir que todos os servios, protocolos e
daemons no seguros estejam adequadamente
protegidos com recursos de segurana
apropriados dificulta que indivduos mal-
intencionados se aproveitem dos pontos de
comprometimento normalmente usados dentro de
uma rede.


2.2.4 Configure os parmetros de
segurana do sistema para impedir o
uso incorreto.

2.2.4.a Questione os administradores do sistema e/ou os
gerentes de segurana para verificar se eles conhecem as
configuraes comuns dos parmetros de segurana
referentes aos componentes do sistema.

Os padres de configurao do sistema de sua
organizao e os processos relacionados devem
abordar especificamente as configuraes e os
parmetros de segurana que tenham
implicaes de segurana conhecidas para cada
tipo de sistema em uso.
2.2.4.b Analise os padres de configurao do sistema para
verificar se as configuraes comuns dos parmetros de
segurana esto includas.
(Continua na prxima pgina)
2.2.4.c Selecione uma amostra dos componentes do sistema
e inspecione os parmetros comuns de segurana para
verificar se eles esto ajustados corretamente e de acordo
com os padres de configurao.
Para que os sistemas sejam configurados
corretamente, os funcionrios responsveis pela
configurao e/ou administrao dos sistemas
devem ter conhecimento dos parmetros
especficos de segurana e ajustes que se
aplicam ao sistema.
2.2.5 Remova todas as
funcionalidades desnecessrias, como
scripts, drivers, recursos, subsistemas,
sistemas de arquivo e servidores Web
desnecessrios.
e inspecione as configuraes para verificar se todas as
funcionalidades desnecessrias (por exemplo, scripts,
drivers, recursos, subsistemas, sistemas de arquivo, etc.)
foram removidas.
Funes desnecessrias podem gerar
oportunidades adicionais para indivduos mal-
intencionados obterem acesso ao sistema.
Removendo funcionalidades desnecessrias, as
organizaes podem se concentrar em proteger
as funes exigidas e reduzir o risco de funes
desconhecidas serem aproveitadas.
Incluir isto nos padres de proteo do servidor e
processos resolve as implicaes de segurana
especficas associadas a funes desnecessrias
(por exemplo, removendo/desativando FTP ou o
servidor Web, caso o servidor no execute essas
funes).
2.2.5.b. Consulte a documentao e os parmetros de
segurana para verificar se as funes ativadas esto
documentadas e suportam a configurao segura.
2.2.5.c. Consulte a documentao e os parmetros de
segurana para verificar se somente as funcionalidades
registradas esto presentes nos componentes do sistema da
amostra.
2.3 Criptografe todo o acesso
administrativo que no utiliza console
durante a criptografia forte. Com o uso
tecnologias como SSH, VPN ou
SSL/TLS para o gerenciamento com
base na Web e outros acessos
administrativos que no utilizam console.
2.3Selecione uma amostra dos componentes do sistema e
verifique se o acesso administrativo que no utiliza console
criptografado realizando o que segue:
Se a administrao que no utiliza console
(incluindo remota) no usa autenticao segura e
comunicaes criptografadas, informaes
confidenciais de nvel administrativo ou
operacional (como as senhas e IDs do
administrador) podero ser reveladas a um
espio. Um indivduo mal-intencionado pode usar
essas informaes para acessar a rede, tornar-se
2.3.a Observe um administrador efetuar logon em cada
sistema e analise as configuraes do sistema para verificar
se o mtodo de criptografia forte invocado antes da senha
do administrador ser solicitada.

2.3.bAnalise os servios e os arquivos de parmetro nos
sistemas para determinar se o Telnet e outros comandos de
logon remoto no seguros no esto disponveis para o
acesso que no utiliza console.
administrador e roubar os dados.
Protocolos de texto simples (como HTTP, telnet,
etc.) no criptografam detalhes de trfego ou
acesso, facilitando que um espio intercepte
estas informaes.
Para serem considerados com "criptografia forte",
os protocolos reconhecidos pelo setor com
resistncias de chave adequadas e
gerenciamento de chave devem estar corretos
conforme aplicvel para o tipo de tecnologia
utilizada. (Consulte criptografia forteno
Glossrio de termos, abreviaes e acrnimos do
PCI DSS e PA-DSS .)
2.3.c Observe um administrador efetuar logon em cada
sistema para verificar se o acesso do administrador s
interfaces de gerenciamento baseadas na Web
criptografado com criptografia forte.
2.3.d Analise a documentao do fornecedor e questione os
funcionrios para verificar se a criptografia forte para a
tecnologia utilizada est implementada de acordo com as
melhores prticas do setor e/ou recomendaes do
fornecedor.
2.4 Mantenha uma relao dos
componentes do sistema que esto no
escopo do PCI DSS.
2.4.a Analise a relao do sistema para verificar se uma lista
de componentes de hardware e software mantida e se inclui
uma descrio da funo/uso de cada um deles.
Manter uma lista atual de todos os componentes
do sistema permite que a organizao defina de
forma precisa e eficaz o escopo de seu ambiente
para implementar os controles do PCI DSS. Sem
uma relao, alguns componentes do sistema
podem ser esquecidos e excludos sem querer
dos padres de configurao da organizao.
2.4.b Questione os funcionrios para verificar se uma relao
documentada mantida no momento.
segurana e procedimentos operacionais
do gerenciamento dos padres do
fornecedor e outros parmetros de
segurana estejam documentados, em
uso e conhecidos por todas as partes
envolvidas.
operacionais do gerenciamento dos padres do fornecedor e
outros parmetros de segurana esto:
Documentados,
Em uso, e
operacionais dirios para garantir que os padres
do fornecedor e outros parmetros de segurana
sejam continuamente gerenciados a fim de evitar
configuraes no seguras.
2.6Os provedores de hospedagem
compartilhada devem proteger cada
ambiente hospedado da entidade e os
dados do portador do carto. Esses
provedores devem atender a requisitos
especficos, conforme detalhado no
Apndice A: Requisitos adicionais do
PCI DSS para provedores de
hospedagem compartilhada.
2.6 Realize os procedimentos de teste de A.1.1 a A.1.4
detalhados no Apndice A: Requisitos adicionais do PCI DSS
para provedores de hospedagem compartilhada para
avaliaes do PCI DSS dos provedores de hospedagem
compartilhada para verificar se os provedores de hospedagem
compartilhada protegem o ambiente hospedado e os dados das
suas entidades (comerciantes e prestadores de servios).
Isso serve para provedores de hospedagem que
oferecem ambientes de hospedagem
compartilhada para vrios clientes no mesmo
servidor. Quando todos os dados estiverem no
mesmo servidor e sob o controle de um nico
ambiente, as configuraes nestes servidores
compartilhados frequentemente no so
gerenciveis pelos clientes individuais. Isto
permite que os clientes adicionem funes e

scripts no seguros que causam impacto na
segurana de todos os outros ambientes de
clientes e, assim, facilitando para um indivduo
mal-intencionado comprometer os dados de um
cliente, obtendo acesso a todos os dados dos
outros clientes. Consulte o Apndice A para
saber detalhes sobre os requisitos.

Proteger os dados do portador do carto
Requisito 3: Proteger os dados armazenados do portador do carto
Mtodos de proteo como criptografia, truncamento, mascaramento e referenciamento so componentes essenciais da proteo de dados do
portador do carto. Se um invasor burlar outros controles de segurana e obtiver acesso aos dados criptografados, sem as chaves criptogrficas
adequadas, os dados estaro ilegveis e inutilizveis para aquele indivduo. Outros mtodos eficientes de proteo dos dados armazenados
tambm devem ser considerados como oportunidades potenciais de minimizao dos riscos. Por exemplo, os mtodos para minimizar os riscos
incluem no armazenar os dados do portador do carto a menos que seja absolutamente necessrio, truncar os dados do portador do carto se
um PAN completo no for necessrio e no enviar o PAN em e-mails no criptografados.
Consulte a seo Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS para obter definies de "criptografia forte" e outros
termos do PCI DSS.
3.1Mantenha a armazenagem dos
dados do portador do carto o mnimo
possvel, implementando polticas,
processos e procedimentos de reteno
e descarte de dados que incluem pelo
menos o que segue para todo o
armazenamento dos dados do portador
do carto (CHD):
Limite da quantia de dados
armazenados e do tempo de
reteno ao que exigido pelos
requisitos legais, regulatrios e
comerciais
Processos para excluso segura de
dados quando no mais necessrios
Requisitos de reteno especficos
para dados de portador do carto
3.1.aAnalise as polticas, processos e procedimentos de
reteno e descarte de dados para verificar se eles incluem
pelo menos o que segue:
Requisitos legais, regulamentares e comerciais para
reteno de dados, incluindo
Requisitos especficos quanto reteno de dados do
portador do carto (por exemplo, os dados do portador do
carto precisam ser retidos por um perodo X por razes
comerciais Y).
Excluso segura dos dados do portador do carto que no
so mais necessrios por motivos legais, regulamentares
ou comerciais
Abrangncia de todo o armazenamento dos dados do
portador do carto
Processos trimestrais para identificar e excluir com
segurana os dados do portador do carto que excederem
os requisitos de reteno definidos.
Polticas formais de reteno de dados
identificam quais dados precisam ser retidos e
onde ficam, de forma a serem excludos ou
destrudos com segurana assim que no forem
mais necessrios.
Os nicos dados do portador do carto que
podem ser armazenados so o nmero da conta
principal ou PAN (desde que ilegvel), data de
vencimento, nome do portador do carto e cdigo
de servio.
necessrio saber onde os dados do portador do
carto esto localizados para que estes sejam
retidos ou descartados corretamente quando no
forem mais necessrios. Para definir os requisitos
de reteno adequados, a empresa dever
primeiro conhecer suas necessidades de
negcios, bem como as responsabilidades legais

Processos trimestrais para identificar
e excluir com segurana os dados do
portador do carto que excederem a
reteno definida.
3.1.b Questione os funcionrios para verificar se:
Todos os locais de armazenamento dos dados do portador
do carto esto includos nos processos de reteno e
descarte de dados.
Um processo trimestral manual ou automtico est
implantado para identificar e excluir com segurana os
dados do portador do carto.
O processo trimestral manual ou automtico realizado
para todos os locais de dados do portador do carto.
e regulamentares que se aplicam setor ou ao
tipo dos dados que sero retidos.

3.1.c Para obter uma amostra dos componentes do sistema
que armazenam dados do portador do carto:
Analise os arquivos e registros do sistema para verificar se
os dados armazenados no excedem os requisitos
definidos na poltica de reteno
Observe o mecanismo de excluso para verificar se os
dados so excludos de forma segura.
Identificar e excluir dados armazenados que
tenham excedido seu perodo de reteno
especificado evita a reteno de dados que no
so mais necessrios. Este processo pode ser
automtico ou manual ou uma combinao dos
dois. Por exemplo, um procedimento
programtico (automtico ou manual) para
localizar e remover dados e/ou uma reviso
manual de reas de armazenamento de dados
pode ser realizado.
Implementar mtodos de excluso seguros
garante que os dados no podero ser
recuperados quando no forem mais
necessrios.
Lembre-se: se voc no precisar, no os
armazene!
3.2 No armazenar dados de
autenticao confidenciais aps a
autorizao (mesmo se estiverem
criptografados). Se forem recebidos
dados de autenticao confidenciais,
processe todos os dados irrecuperveis
ao completar o processo de autorizao.
O armazenamento de dados de
3.2.a Para os emissores e/ou empresas que suportam servios
de emisso e armazenam dados de autenticao confidenciais,
revise as polticas e questione os funcionrios para verificar se
h justificativa comercial documentada para o armazenamento
de dados de autenticao confidenciais.
Os dados de autenticao confidenciais so
formados por dados de rastreamento completo,
cdigo ou valor de validao do carto e dados
do PIN. O armazenamento de dados de
autenticao confidenciais aps a autorizao
proibido! Esses dados so muito valiosos para
indivduos mal-intencionados, pois permitem
falsificar cartes de pagamento e criar transaes
fraudulentas.

autenticao confidenciais permitido
aos emissores e empresas que
suportam servios de emisso se:
Houver uma justificativa comercial e
Os dados so armazenados com
segurana.
Os dados de autenticao confidenciais
incluem os dados conforme
mencionados nos seguintes Requisitos
3.2.1 at 3.2.3:
3.2.b Para os emissores e/ou empresas que suportam servios
de emisso e armazenam dados de autenticao confidenciais,
analise o armazenamento de dados e configuraes do
sistema para verificar se os dados de autenticao
confidenciais esto seguros.
As entidades que emitem cartes de pagamento
ou que desempenham ou suportam servios de
emisso, frequentemente criaro e controlaro os
dados de autenticao confidenciais como parte
da funo de emisso. As empresas que
executam, facilitam ou suportam servios de
emisso tm permisso para armazenar dados de
autenticao confidenciais SOMENTE SE
apresentarem legtima necessidade de negcios
para armazenar esses dados.
Deve-se observar que todos os requisitos de PCI
DSS se aplicam aos emissores e a nica exceo
para emissores e processadores de emisses
que os dados de autenticao confidenciais
podero ficar retidos se houver uma razo
legtima para tanto. Razo legtima aquela
necessria para o desempenho da funo
fornecida para o emissor e no de convenincia.
Esses dados devero ser armazenados com
segurana e de acordo com o PCI DSS e os
requisitos especficos da empresa de pagamento.
3.2.c Para todas as outras entidades, se dados de autenticao
confidenciais forem recebidos, revise as polticas e
procedimentos e analise as configuraes do sistema para
verificar se os dados no esto retidos aps a autorizao.
3.2.d Para todas as outras entidades, se dados de
autenticao confidenciais forem recebidos, revise os
procedimentos e analise os processos de excluso dos dados
para verificar se os dados so irrecuperveis.
Para entidades que no executam servios de
emisso, no permitido reter os dados de
autenticao confidenciais aps a autenticao.

3.2.1 No armazene o contedo
completo de qualquer rastreamento
(da tarja magntica localizada na parte
posterior do carto, em dados
equivalentes constando no chip ou
outro local). Esses dados tambm so
denominados como rastreamento
completo, rastreamento, rastreamento
1, rastreamento 2 e dados da tarja
magntica.
Observao: No curso normal dos
negcios, os seguintes elementos de
dados da tarja magntica talvez
precisem ser mantidos:
O nome do portador do carto
O nmero da conta principal (PAN)
Data de vencimento
O cdigo de servio
Para minimizar o risco, armazene
somente os elementos de dados
conforme necessrio para os negcios.
3.2.1 Para obter uma amostra dos componentes do sistema,
analise as fontes de dados, inclusive, entre outros, o que
segue e verifique se o contedo completo de qualquer
rastreamento da tarja magntica na parte posterior do carto
ou dados equivalentes em um chip no so armazenados
aps a autorizao:
Dados de transao de entrada
Todos os registros (por exemplo, transao, histrico,
depurao, erro)
Arquivos do histrico
Arquivos de rastreamento
Vrios esquemas do banco de dados
Contedo de bancos de dados.
Se os dados de rastreamento completo forem
armazenados, os indivduos mal-intencionados
que obtiverem esses dados podero reproduzir os
cartes de pagamento e realizar transaes
fraudulentas.

3.2.2 No armazene o cdigo ou valor
de verificao do carto (o nmero de
trs ou quatro dgitos impresso na
frente ou atrs do carto de
pagamento) usado para verificar as
transaes sem o carto.
3.2.2Para obter uma amostra dos componentes do sistema,
analise as fontes dos dados, inclusive, entre outros, o que
segue e verifique se o cdigo ou o valor de verificao do
carto de trs ou quatro dgitos impresso na frente do carto
ou no painel de assinatura (dados CVV2, CVC2, CID, CAV2)
no armazenado aps a autorizao:
depurao, erro)
O objetivo do cdigo de validao do carto
proteger as transaes do tipo "carto no
presente", aquelas feitas por internet, por correio
ou telefone (MO/TO), nas quais o consumidor e o
carto no esto presentes.
Se esses dados forem roubados, indivduos mal-
intencionados podem executar transaes
fraudulentas pela internet e por MO/TO.

3.2.3 No armazene o PIN (Personal
Identification Number) ou o bloco de
PIN criptografado.
3.2.3Para obter uma amostra dos componentes do sistema,
analise as informaes a seguir e verifique se os PINs e
blocos de PIN criptografados no so armazenados aps a
autorizao:
depurao, erro)
Esses valores s devem ser conhecidos pelo
proprietrio do carto ou pelo banco que emitiu o
carto. Se esses dados forem roubados,
indivduos mal-intencionados podem executar
transaes fraudulentas de dbito protegidas por
senha (por exemplo, saques em caixas
eletrnicos).
3.3 Mascare o PAN quando exibido (os
primeiros seis e quatro ltimos dgitos
so o nmero mximo de dgitos a
serem exibidos), como no caso em que
apenas funcionrios com necessidade
comercial legtima podem visualizar o
PAN completo.
Observao: Esse requisito no
substitui os requisitos mais rigorosos em
vigor quanto s exibies dos dados do
portador do carto, por exemplo,
requisitos legais ou da bandeira do
carto de pagamento para recebimentos
do ponto de venda (POS).
3.3.a Analise as polticas e procedimentos escritos sobre a
mascaragem da exibio de PANs para verificar se:
Uma lista de funes que precisam acessar as exibies do
PAN completo est documentada, junto com uma
necessidade comercial legtima para que cada funo tenha
este acesso.
O PAN deve ser mascarado quando exibido, como no caso
em que apenas funcionrios com necessidade comercial
legtima podem ver o PAN completo.
Todas as outras funes no autorizadas especificamente
para visualizar o PAN completo devem visualizar apenas os
PANs mascarados.
A exibio do PAN completo em locais como telas
de computador, recibos de carto de pagamento,
faxes ou extratos em papel pode fazer com que
esses dados sejam obtidos por indivduos no
autorizados e usados de forma fraudulenta.
Garantir que o PAN completo seja exibido apenas
para aqueles com necessidade comercial legtima
de visualizar o PAN completo minimiza o risco de
pessoas no autorizadas obterem acesso aos
dados do PAN.
Este requisito est relacionado proteo do
PAN exibida em telas, recibos, impresses, etc. e
no deve ser confundido com o Requisito 3.4
para proteo do PAN quando armazenado em
arquivos, bancos de dados, etc.
3.3.b Analise as configuraes do sistema para verificar se o
PAN completo exibido apenas para usurios/funes com
uma necessidade comercial documentada e que o PAN esteja
mascarado para todas as outras solicitaes.
3.3.c Analise as exibies do PAN (por exemplo, na tela, em
recibos) para verificar se os PANs esto mascarados ao exibir
os dados do portador do carto e que apenas as pessoas que
tenham uma necessidade comercial legtima possam visualizar
o PAN completo.

3.4Torne o PAN ilegvel em qualquer
local onde ele esteja armazenado
(inclusive em mdia digital porttil, mdia
de backup e em registros) utilizando
qualquer uma das seguintes
abordagens:
Hash de direo nica com base na
criptografia forte (o hash deve ser do
PAN inteiro)
Truncamento (a codificao hash
no pode ser usada para substituir o
segmento truncado do PAN)
Tokens e blocos de ndice (os blocos
devem ser armazenados de forma
segura)
Criptografia forte com processos e
procedimentos de gerenciamento-
chave associados.
3.4.a Analise a documentao sobre o sistema usado para
proteger o PAN, incluindo o fornecedor, o tipo de
sistema/processo e os algoritmos de criptografia (se aplicvel)
para verificar se o PAN apresentado ilegvel, usando
qualquer um dos mtodos a seguir:
Codificao hash de direo nica com base na criptografia
forte,
Truncamento
Tokens e blocos de ndice, sendo que os blocos so
armazenados de forma segura
Criptografia forte com processos e procedimentos de
gerenciamento-chave associados.
Os PANs armazenados no armazenamento
principal (bancos de dados ou arquivos simples,
como arquivos de texto e planilhas), alm de
armazenamento no principal (backup, logs de
auditoria, logs de exceo ou de resoluo de
problemas) devem todos estar protegidos.
Funes de hash de direo nica baseadas em
uma criptografia forte podem ser usadas para
deixar os dados do portador do carto ilegveis.
As funes de condificao de hash so
adequadas quando no houver necessidade de
recuperar o nmero original (o hash de direo
nica irreversvel). Recomenda-se, mas no
um requisito atual, que um valor de entrada
adicional e aleatrio seja adicionado aos dados
do portador do carto antes da codificao hash
para reduzir a possibilidade de um invasor
comparar os dados com (e produzir o PAN a
partir das) tabelas de valores de hash pr-
3.4.bAnalise as diversas tabelas ou arquivos de um exemplo
de repositrios de dados para verificar se o PAN foi tornado
ilegvel (ou seja, no foi armazenado em texto simples).
3.4.cAnalise um exemplo de mdia removvel (por exemplo,
fitas de backup) paa confirmar se o PAN foi tornado ilegvel.

Observao: um esforo
relativamente simples para um indivduo
mal-intencionado reconstituir os dados
do PAN original caso ele tenha acesso
s verses truncadas e hash do PAN.
Quando as verses truncada e hash do
mesmo PAN estiverem presentes no
ambiente de uma entidade, controles
adicionais devero ser implantados para
assegurar que as verses truncada e
hash no sejam correlacionadas para
reconstituir o PAN original.
3.4.d Analise uma amostra de logs de auditoria para confirmar
se o PAN tornou-se ilegvel ou foi removido dos logs.
computados.
O objetivo do truncamento que somente uma
parte (sem exceder os primeiro seis e os ltimos
quatro dgitos) do PAN seja armazenado.
Um token de ndice um token criptogrfico que
substitui o PAN com base em um determinado
ndice para um valor imprevisvel. Um pad de uso
nico um sistema no qual uma chave privada
gerada aleatoriamente usada s uma vez para
criptografar uma mensagem que ento
descodificada usando um pad e uma chave de
uso nico correspondentes.
O objetivo da criptografia forte (conforme definido
noGlossrio de termos, abreviaes e acrnimos
do PCI DSS e PA-DSS) que a criptografia se
baseie em um algoritmo testado e aceito pela
empresa (no um algoritmo feito em casa) com
chaves de criptografia forte.
Ao correlacionar as verses de hash e truncada
de um determinado PAN, um indivduo mal-
intencionado poder facilmente derivar o valor do
PAN original. Os controles que evitam a
correlao desses dados ajudaro a garantir que
o PAN original permanea ilegvel.
3.4.1 Se a criptografia de dados for
utilizada (em vez da criptografia de
bancos de dados no nvel de arquivo
ou coluna), o acesso lgico deve ser
gerenciado separadamente e
independentemente de mecanismos
de controle de acesso e autenticao
do sistema operacional nativo (por
exemplo, no utilizando bancos de
dados de contas de usurio locais ou
credenciais gerais de logon da rede).
Chaves de decodificao no devem
estar associadas a contas de usurios.
3.4.1.a Se a criptografia de dados for usada, inspecione a
configurao e observe o processo de autenticao para
verificar se o acesso lgico aos sistemas de arquivos
criptografados foi implementado por meio de um mecanismo
que seja separado do mecanismo de autenticao do sistema
operacional nativo (por exemplo, no usando os bancos de
dados das contas de usurio locais ou credenciais gerais de
logon da rede).
O objetivo deste requisito abordar a
aceitabilidade da criptografia no nvel de disco
para deixar os dados do portador do carto
ilegveis. A criptografia no nvel de disco codifica
todas os discos/divises em computador e
descodifica automaticamente as informaes
quando um usurio autorizado as solicita. Muitas
solues de criptografia de dados interceptam as
operaes de leitura/gravao do sistema
operacional e executam as transformaes
criptogrficas adequadas sem nenhuma ao
especial por parte do usurio, alm de fornecer
uma senha ao ligar o sistema ou no incio de uma
sesso. Com base nessas caractersticas de
3.4.1.bObserve os processos e questione os funcionrios
para verificar se as chaves criptogrficas so armazenadas
de forma segura (por exemplo, armazenadas nas mdias
removveis que esto protegidas adequadamente com
controles de acesso robustos).

3.4.1.c Analise as configuraes e observe os processos
para verificar se os dados do portador do carto nas mdias
removveis esto criptografados onde quer que estejam
armazenados.
Observao: Se a criptografia de dados no for usada para
criptografar a mdia removvel, os dados armazenados nessa
mdia devero ser tornados ilegveis por meio de outro mtodo.
criptografia no nvel de disco, a fim de atender a
esse requisito, o mtodo no pode:
1) Utilizar o mesmo autenticador de conta do
usurio que o sistema operacional, ou
2) Utilizar uma chave de descodificao
associada com ou derivada do banco de
dados da conta do usurio local do sistema
ou credenciais gerais de logon da rede.
A criptografia de dados completa ajuda a proteger
os dados no caso de perda de um disco e,
portanto, pode ser apropriada para dispositivos
portteis que armazenam dados do portador do
carto.
3.5 Registre e implemente os
procedimentos para proteger as chaves
utilizadas para armazenar de forma
segura os dados do portador do carto
em relao a divulgaes ou mau uso:
Observao: Esse requisito se aplica a
chaves usadas para proteger os dados
armazenados do portador do carto e
tambm a chaves de criptografia de
dados, essas chaves de criptografia de
chaves devem ser ao menos to fortes
quanto as chaves de criptografia de
dados.
3.5 Analise as polticas e procedimentos de gerenciamento de
chave para verificar se os processos esto especificados para
proteger as chaves usadas para a criptografia dos dados do
portador do carto contra a divulgao e o uso incorreto e se
incluem pelo menos o que segue:
O acesso s chaves est restrito ao menor nmero
necessrio de responsveis pela proteo.
As chaves de criptografia de chaves so to fortes quanto
as chaves de criptografia de dados que protegem.
As chaves de criptografia de chaves so armazenadas
separadamente das chaves de criptografia.
As chaves so armazenadas de forma segura no menor
nmero possvel de locais e formatos.
As chaves criptogrficas devem ser muito bem
protegidas, pois quem tiver acesso a elas
conseguir decodificar os dados. As chaves de
criptografia de chaves, se utilizadas, devero ser
ao menos to fortes quanto as chaves de
criptografia de dados para garantir a proteo
adequada da chave que criptografa os dados e
dos dados criptografados por essa chave.
O requisito para proteger chaves da divulgao e
do uso indevido se aplica tanto s chaves de
criptografia de dados quanto s chaves de
criptografia de chaves. Como uma chave de
criptografia de chaves poder conceder direito de
acesso a vrias chaves de criptografia de dados,
as chaves de criptografia de chaves necessitam
de medidas de proteo vigorosas.
3.5.1Restrinja o acesso s chaves
criptogrficas ao menor nmero
necessrio de responsveis pela
proteo.
3.5.1 Analise as listas de acesso dos usurios para verificar
se o acesso s chaves est restrito a poucos responsveis
pela proteo.
Deve haver pouqussimas pessoas com acesso
s chaves criptogrficas (reduzindo o potencial de
deixar os dados do portador do carto visveis
para pessoas no autorizadas), normalmente s
aquelas com responsabilidades de custdia de
chaves.

3.5.2 Armazene chaves privadas e
secretas usadas para
criptografar/descodificar os dados do
portador do carto em uma (ou mais)
das formas a seguir em todos os
momentos:
Criptografadas com uma chave de
criptografia de chaves que seja ao
menos to forte quanto a chave de
criptografia de dados e que esteja
armazenada separadamente da
chave de criptografia de dados.
Dentro de um dispositivo
criptogrfico seguro (como um
mdulo de segurana de
hospedagem (HSM) ou dispositivo
PTS de interao de ponto
aprovado)
Como duas partes de chave ou
componentes de chave de
tamanho total, de acordo com um
mtodo aceito pela empresa
Observao: No exigido que chaves
pblicas sejam armazenadas em uma
destas formas.
3.5.2.a Analise os procedimentos documentados para
verificar se as chaves criptogrficas usadas para
criptografar/descodificar os dados do portador do carto
devem existir em apenas uma (ou mais) das formas a seguir
em todos os momentos.
Criptografadas com uma chave de criptografia de chaves
que seja ao menos to forte quanto a chave de
criptografia de dados e que esteja armazenada
separadamente da chave de criptografia de dados.
Dentro de um dispositivo criptogrfico seguro (como um
mdulo de segurana de hospedagem (HSM) ou
dispositivo PTS de interao de ponto aprovado)
Como partes de chave ou componentes de chave, de
acordo com um mtodo aceito pela empresa
Chaves criptogrficas devem ser armazenadas
com segurana para evitar o acesso no
autorizado e desnecessrio que pode resultar na
exposio dos dados do portador do carto.
As chaves de criptografia de chaves no
precisam ser criptografadas, mas devem ficar
protegidas contra divulgao e uso indevido
conforme definido no Requisito 3.5. Se forem
usadas chaves de criptografia de chave,
armazen-las em locais fisicamente e/ou
logicamente separados das chaves de criptografia
de dados reduz os riscos de acesso no
autorizado s duas chaves.
3.5.2.b Analise as configuraes do sistema e os locais de
armazanamento de chave para verificar se as chaves
criptogrficas usadas para criptografar/descodificar os dados
do portador do carto existem em uma (ou mais) das formas
a seguir em todos os momentos.
Criptografadas com uma chave de criptografia de chave
Dentro de um dispositivo criptogrfico seguro (como um
mdulo de segurana de hospedagem (HSM) ou
dispositivo PTS de interao de ponto aprovado)
Como partes de chave ou componentes de chave, de
acordo com um mtodo aceito pela empresa
3.5.2.c Onde quer que as chaves de criptografia de chave
sejam usadas, analise as configuraes do sistema e os
locais de armazenamento de chave para verificar se:
As chaves de criptografia de chaves so to fortes
quanto as chaves de criptografia de dados que protegem
As chaves de criptografia de chaves so armazenadas
separadamente das chaves de criptografia.

3.5.3 Armazene chaves criptogrficas
no menor nmero possvel de locais.
3.5.3 Analise os locais de armazenamento de chave e
observe os processos para verificar se as chaves so
armazenadas no menor nmero possvel de locais.
Armazenar chaves criptogrficas no menor
nmero possvel de locais ajuda a organizao a
acompanhar e monitorar todos os locais de
chaves e minimiza o potencial das chaves serem
expostas a pessoas no autorizadas.
3.6 Documente e implemente por
completo todos os processos e
procedimentos de gerenciamento de
chave com relao s chaves
criptogrficas usadas para a criptografia
dos dados do portador do carto,
incluindo o seguinte:
Observao: Vrios padres do setor
para o gerenciamento-chave esto
disponveis a partir de diversos recursos,
incluindo NIST, que pode ser encontrado
em http://csrc.nist.gov.
3.6.a Procedimento de teste adicional para prestadores de
servios: Se o prestador de servios compartilhar chaves com
seus clientes para a transmisso ou armazenamento de dados
do portador do carto, analise a documentao que o prestador
de servios fornece aos clientes para verificar se ela inclui uma
orientao sobre como transmitir, armazenar e atualizar as
chaves do cliente de forma segura, de acordo com os
Requisitos 3.6.1 a 3.6.8 abaixo.
A forma como as chaves criptogrficas so
gerenciadas parte essencial da segurana
continuada da soluo de criptografia. Um bom
processo de gerenciamento de chaves, seja ele
manual ou automatizado, como parte do produto
de criptografia, baseia-se nos padres do setor e
aborda todos os elementos de chave em 3.6.1 a
3.6.8.
Fornecer orientao aos clientes sobre como
transmitir, armazenar e atualizar as chaves
criptogrficas com segurana pode ajudar a evitar
que as chaves sejam mal administradas ou
divulgadas a entidades no autorizadas.
Este requisito se aplica s chaves utilizadas para
criptografar os dados do portador do carto
armazenados e a qualquer chave de criptografia
de chaves respectiva.
3.6 Analise os processos e procedimentos de gerenciamento
de chave com relao s chaves usadas para a criptografia dos
dados do portador do carto e faa o seguinte:
3.6.1 Gerao de chaves criptogrficas
fortes
3.6.1.a Verifique se os procedimentos de gerenciamento-
chave especificam como gerar chaves fortes.
A soluo de criptografia deve gerar chaves
fortes, conforme definido no Glossrio de termos,
abreviaes e acrnimos do PCI DSS e PA-DSS,
em "criptografia forte". O uso de chaves
criptogrficas fortes aumenta significativamente o
nvel de segurana dos dados criptografados do
portador do carto.
3.6.1.b Observe o mtodo de gerao de chaves para
verificar se chaves fortes so geradas.
3.6.2 Distribuio segura da chave
criptogrfica
chave especificam como distribuir chaves de forma segura.
A soluo de criptografia deve distribuir as chaves
de forma segura, o que significa que as chaves
so distribudas somente para os responsveis
identificados em 3.5.1 e nunca distribudas sem
limitao.
3.6.2.b Observe o mtodo de distribuio de chaves para
verificar se elas so distribudas de forma segura.
3.6.3 Armazenamento seguro de
chaves criptogrficas
chave especificam como armazenar chaves de forma segura.
A soluo de criptografia deve armazenar as
chaves com segurana, por exemplo,

3.6.3.b Observe o mtodo de armazenamento das chaves
para verificar se elas esto armazenadas com segurana.
criptografando-as com uma chave de criptografia.
Armazenar as chaves sem proteo adequada
pode dar acesso aos invasores, resultando na
descodificao e exposio dos dados do
portador do carto.
3.6.4 Troca de chave criptogrfica para
as chaves que chegaram ao final de
seu criptoperodo (por exemplo, aps
ter passado determinado perodo de
tempo e/ou aps certa quantidade de
texto cifrado ter sido produzido por
dada chave), conforme definido pelo
fornecedor associado do aplicativo ou
o dono da chave e com base nas
melhores prticas e orientaes do
setor (por exemplo, a Publicao
Especial NIST 800-57).
chave incluem um criptoperodo definido para cada tipo de
chave em uso e se define um processo para modificaes de
chave no final do criptoperodo definido.
Um criptoperodo o tempo transcorrido durante
o qual uma determinada chave de criptografia
poder ser utilizada para seus devidos fins. As
consideraes para definir o criptoperodo
incluem, entre outros, a fora do algoritmo em
destaque, o tamanho ou o comprimento da chave,
o risco de comprometimento da chave e a
confidencialidade dos dados a serem
criptografados.
A troca peridica das chaves de criptografia ao
atingirem o criptoperodo essencial para
minimizar o risco de algum obter as chaves de
criptografia e us-las para decodificar os dados.
3.6.4.b Questione os funcionrios para verificar se as chaves
so modificadas no final do criptoperodo definido.
3.6.5 Inutilizao ou substituio (por
exemplo, arquivamento, destruio
e/ou revogao) de chaves
consideradas necessrias quando a
integridade da chave estiver
enfraquecida (por exemplo, sada de
um funcionrio com conhecimento
sobre um componente de chave de
texto simples) ou quando houver
suspeita de que a chave esteja
comprometida.
Observao: Caso chaves
criptogrficas inutilizadas ou recolocadas
precisarem ser retidas, essas chaves
chave especificam processos para o que segue:
A inutilizao ou substituio de chaves quando sua
integridade tiver sido enfraquecida
A substituio de chaves que estejam sabidamente ou
potencialmente comprometidas.
Qualquer chave mantida aps a inutilizao ou
substituio no so utilizadas para operaes de
criptografia
Chaves que no so mais usadas nem
necessrias ou chaves que se sabe ou so
suspeitas de estarem comprometidas devem ser
inutilizadas e/ou destrudas para garantir que no
possam mais ser usadas. Se for necessrio
mant-las (para usar com dados arquivados e
criptografados, por exemplo), elas devero ser
muito bem protegidas.
A soluo de criptografia deve fornecer e facilitar
o processo para substituir as chaves que estejam
no prazo de substituio, ou sabidamente ou
3.6.5.b Questione os funcionrios para verificar se os
seguintes processos esto implementados:
As chaves so inutilizadas ou substitudas quando sua
integridade tenha sido enfraquecida, incluindo quando

devero ser arquivadas em segurana
(por exemplo, usando uma chave de
criptografia de chaves). Chaves
criptogrficas arquivadas devem ser
usadas somente para fins de
decodificao/verificao.
algum com conhecimento sobre a chave sai da
empresa.
As chaves so substitudas se estiverem sabidamente ou
Qualquer chave mantida aps a inutilizao ou
substituio no so utilizadas para operaes de
criptografia.
3.6.6 Se forem usadas operaes
manuais de gerenciamento de chave
criptogrfica de texto simples, essas
operaes devem ser gerenciadas
com o uso de conhecimento separado
e de controle duplo.
Observao: Os exemplos de
operaes manuais de gerenciamento
de chave incluem, entre outros: gerao,
transmisso, carregamento,
armazenamento e destruio de chaves.
3.6.6.a Verifique se os procedimentos manuais de
gerenciamento-chave de texto simples especificam
processos para o uso do que segue:
O conhecimento separado de chaves, como os
componentes de chaves que esto sob o controle de
pelo menos duas pessoas que tm conhecimento
apenas de seus prprios componentes de chave; E
Controle duplo de chaves, que necessita de pelo menos
duas pessoas para executar qualquer operao de
gerenciamento-chave e que uma nica pessoa no
tenha acesso aos materiais de autenticao (por
exemplo, senhas ou chaves) do outro.
O conhecimento separado e o controle duplo das
chaves so usados para eliminar a possibilidade
de uma pessoa ter acesso chave inteira. Este
controle aplicvel em operaes de
gerenciamento de chaves manual ou onde o
gerenciamento de chaves no for implementado
por um produto de criptografia.
O conhecimento separado um mtodo no qual
duas ou mais pessoas possuem componentes de
chave separadamente, onde cada pessoa
conhece apenas seu prprio componente e os
componentes de chave individuais no
transmitem nenhum conhecimento da chave
criptogrfica original).
O controle duplo requer que duas ou mais
pessoas realizem uma funo e uma nica
pessoa no pode acessar ou usar os materiais de
autenticao do outro.
3.6.6 Questione os funcionrios e/ou observe os processos
para verificar se as chaves manuais de texto simples so
gerenciadas com:
Conhecimento separado, E
Controle duplo
3.6.7 Preveno contra a substituio
no autorizada de chaves
criptogrficas.
3.6.7.a Verifique se os procedimentos do gerenciamento de
chaves especificam processos para evitar a substituio no
autorizada das chaves.
A soluo de criptografia no deve permitir nem
aceitar a substituio de chaves vindas de fontes
no autorizadas ou de processos inesperados.
3.6.7.b Questione os funcionrios e/ou observe os processos
para verificar se a substituio no autorizada de chaves
evitada.
3.6.8 Requisito para que os
responsveis pela proteo das
chaves criptogrficas assinem um
formulrio declarando que eles
compreendem e aceitam suas
3.6.8.a Verifique se os procedimentos do gerenciamento de
chaves especificam processos para que os responsveis pela
proteo garantam (por escrito ou eletronicamente) que
compreendem e aceitam suas responsabilidades de proteo
das chaves.
Este processo garantir que os indivduos que
atuam como responsveis se comprometam com
a funo de responsveis pela chave e conheam
e aceitem as responsabilidades.

responsabilidades pela proteo das
chaves.
3.6.8.b Observe a documentao ou outras evidncias que
demonstrem se os responsveis pela proteo garantem (por
escrito ou eletronicamente) que compreendem e aceitam
suas responsabilidades de proteo das chaves.
para proteger os dados armazenados do
portador do carto estejam
documentados, em uso e conhecidos por
todas as partes envolvidas.
operacionais para proteger os dados armazenados do carto
esto:
Documentados,
Em uso, e
operacionais documentados para gerenciar o
armazenamento seguro dos dados do portador do
carto continuamente.
Requisito 4: Criptografe a transmisso dos dados do portador do carto em redes abertas e pblicas
As informaes confidenciais devem ser criptografadas durante a transmisso nas redes que so facilmente acessadas por indivduos mal-
intencionados. Redes sem fio configuradas de forma incorreta e vulnerabilidades na criptografia herdada e protocolos de autenticao continuam
a ser alvos contnuos de indivduos mal-intencionados que exploram essas vulnerabilidades para obter acesso privilegiado aos ambientes de
4.1 Uso de criptografia forte e protocolos
de segurana (por exemplo, SSL/TLS,
IPSEC, SSH, etc.) para proteger dados
confidenciais do portador do carto
durante a transmisso por redes
pblicas e abertas, incluindo o que
segue:
Somente chaves e certificados
confiveis so aceitos.
O protocolo em uso suporta apenas
verses ou configuraes seguras.
A fora da criptografia adequada
para a metodologia de criptografia
que est sendo utilizada.
4.1.a Identifique todos os locais onde os dados do portador do
carto so transmitidos ou recebidos por redes pblicas,
abertas. Analise os padres documentados e compare com as
configuraes do sistema para verificar o uso de protocolos de
segurana e criptografia forte em todos os locais.
As informaes confidenciais devem ser
criptografas durante a transmisso por redes
pblicas, pois fcil e comum para um indivduo
mal-intencionado interceptar e/ou desviar os
dados enquanto eles estiverem em trnsito.
A transmisso segura dos dados do portador do
carto requer o uso de chaves/certificados
confiveis, um protocolo seguro para o transporte
e criptografia forte adequada para criptografar os
dados do portador do carto. As solicitaes de
conexo de sistemas que no suportam a
criptografia forte adequada e que possam resultar
em uma conexo no segura, no devem ser
aceitas.
4.1.b Revise as polticas e procedimentos documentados para
verificar se os processos so especificados para o que segue:
Aceitao de apenas chaves e/ou certificados confiveis
O protocolo em uso suporta apenas verses e
configuraes seguras (verses e configuraes no
seguras no so suportadas)
Implementao de fora de criptografia adequada
conforme a metodologia de criptografia que est sendo
utilizada.

Os exemplos de redes abertas e
pblicas incluem, entre outros:
A internet
Tecnologias sem fio, incluindo
802.11 e Bluetooth
Tecnologia celular, por exemplo,
Global System for Mobile
Communications (GSM), Code
Division Multiple Access (CDMA)
General Packet Radio Service
(GPRS).
Comunicaes por satlite.
4.1.c Selecione e observe uma amostra das transmisses de
entrada e sada conforme elas ocorrem para verificar se os
dados do portador do carto esto bem criptografados durante
o trnsito.
Observe que algumas implantaes de protocolo
(como SSL verso 2.0, SSH verso 1.0 e TLS
1.0) possuem vulnerabilidades conhecidas que
um invasor poder utilizar para obter o controle
do sistema afetado. Qualquer que seja o
protocolo de segurana adotado, verifique que
esteja configurado para utilizar somente
configuraes e verses seguras para evitar o
uso de uma conexo no segura. Por exemplo, o
TLS v1.1 ou mais recente, certificados obtidos a
partir de uma autoridade pblica e reconhecida e
que suporte apenas critptografia forte, podem ser
considerados.
Verificar se os certificados so confiveis (por
exemplo, que no estejam vencidos e que sejam
emitidos a partir de uma fonte confivel) ajuda a
garantir a integridade da conexo segura.
4.1.dAnalise as chaves e certificados para verificar se somente
chaves e/ou certificados confiveis so aceitos.
4.1.e Analise as configuraes do sistema para verificar se o
protocolo foi implementado para usar apenas configuraes
seguras e se no suportam verses ou configuraes no
seguras.
4.1.f Analise as configuraes do sistema para verificar se a
fora da criptografia adequada implementada para a
metodologia de criptografia que est sendo utilizada. (Verifique
as recomendaes/melhores prticas do fornecedor.)
4.1.g Para as implementaes de SSL/TLS, analise as
configuraes do sistema para verificar se o SSL/TLS est
habilitado onde quer que os dados do portador do carto sejam
transmitidos ou recebidos.
Por exemplo, para implementaes com base no navegador:
O "HTTPS" aparece como parte do protocolo de
Universal Record Locator (URL) do navegador, e
Os dados do portador do carto so exigidos somente se
o "HTTPS" aparece como parte do URL.
Geralmente, o URL da pgina Web inicia com
"HTTPS" e/ou o navegador da Web exibe um
cone de cadeado em algum lugar na janela do
navegador. Muitos fornecedores de certificados
SSL tambm fornecem um selo de verificao
bem visvel, s vezes chamados de "selo de
segurana", "selo de local seguro" ou "selo
confivel seguro"), o qual possibilita clicar no selo
para revelar as informaes sobre o site.

4.1.1 Certifique-se de que as redes
sem fio estejam transmitindo dados do
portador do carto ou estejam
conectadas ao ambiente de dados do
portador do carto, use as melhores
prticas do setor (por exemplo, IEEE
802.11i) para implementar a
criptografia forte para a autenticao e
a transmisso.
Observao: O uso de WEP como
controle de segurana proibido.
4.1.1 Identifique todas as redes sem fio que transmitem
dados do portador do carto ou conectadas ao ambiente de
dados do portador do carto. Analise os padres
documentados e compare com as configuraes do sistema
para verificar o que segue para todas as redes sem fio
identificadas:
As melhores prticas do setor (por exemplo, IEEE
802.11i) so usadas para implementar a criptografia forte
para autenticao e transmisso.
A criptografia fraca (por exemplo, WEP, SSL verso 2.0
ou mais antiga) no utilizada como controle de
segurana para a autenticao ou transmisso.
Usurios mal-intencionados usam as vrias
ferramentas que esto disponveis gratuitamente
para espionar as comunicaes sem fio. O uso de
criptografias fortes pode limitar a divulgao de
informaes confidenciais atravs da rede sem
fio.
A criptografia forte para autenticao e
transmisso dos dados do portador do carto
necessria para evitar que usurios mal-
intencionados obtenham acesso rede sem fio
ou utilizem as redes sem fio para acessar outros
dados ou redes internos.
4.2 Nunca envie PANs desprotegidos
por tecnologias de envio de mensagens
de usurio final (por exemplo, e-mail,
sistemas de mensagens instantneas,
chat, etc.).
4.2.a Se forem utilizadas tecnologias de mensagem de usurio
final para enviar dados do portador do carto, observe os
processos de envio do PAN e analise uma amostra das
transmisses de sada quando elas ocorrerem para verificar se
o PAN entregue ilegvel ou protegido com criptografia forte
sempre que enviado por meio de tecnologias de mensagens
de usurio final.
E-mail, sistemas de mensagens instantneas e
chat podem ser facilmente interceptados por
sniffing de pacotes durante a entrega por redes
internas e pblicas. No utilize essas ferramentas
de envio de mensagem para enviar o PAN se elas
no estiverem configuradas para fornecer
criptografia forte.

4.2.bRevise as polticas escritas para verificar a existncia de
uma poltica que afirme que os PANs desprotegidos no devem
ser enviados por meio das tecnologias de envio de mensagens
de usurio final.
para criptografar as transmisses dos
dados do portador do carto estejam
operacionais para criptografar as transmisses dos dados do
portador do carto esto:
Documentados,
Em uso, e
operacionais para gerenciar a transmisso segura
dos dados do portador do carto continuamente.

Manter um programa de gerenciamento de vulnerabilidades
Requisito 5: Proteja todos os sistemas contra softwares prejudiciais e atualize regularmente programas ou software de
antivrus
Softwares mal-intencionados, normalmente chamados de "malware" (incluindo vrus, worms e cavalos de Troia) adentram a rede durante muitas
atividades de negcios aprovadas, incluindo e-mail dos funcionrios e uso da internet, computadores mveis e dispositivos de armazenamento,
resultando na explorao das vulnerabilidades do sistema. O software de antivrus deve ser usado em todos os sistemas comumente afetados
pelo malware para proteger os sistemas de ameaas atuais e potenciais de softwares mal-intencionados. Solues adicionais contra malware
podem ser consideradas como suplemento ao software de antivrus; no entanto, estas solues adicionais no substituem a necessidade do
software de antivrus estar adequado.
Requisitos do PCI DSS PROCEDIMENTOS DE TESTE ORIENTAO
5.1 Implemente softwares de antivrus
em todos os sistemas normalmente
afetados por softwares mal-
intencionados (especialmente em
computadores pessoais e servidores).
5.1Para obter uma amostra dos componentes do sistemas
incluindo todos os tipos de sistemas operacionais normalmente
afetados por softwares mal-intencionados, verifique se o
software de antivrus foi implementado se houver uma
tecnologia antivrus aplicvel.
Existe um fluxo constante de invases usando
faanhas amplamente divulgadas, muitas vezes
do tipo "zero day" (uma invaso que se aproveita
de uma vulnerabilidade previamente
desconhecida), contra sistemas at ento
seguros. Sem uma soluo de antivrus que seja
atualizada regularmente, essas novas formas de
software mal-intencionado podem atacar os
sistemas, desativar uma rede ou levar ao
comprometimento dos dados.
5.1.1 Certifique-se de que os
programas antivrus sejam capazes de
detectar, remover e proteger contra
todos os tipos conhecidos de softwares
mal-intencionados.
5.1.1 Revise a documentao do fornecedor e analise as
configuraes do antivrus para verificar se os programas
antivrus;
Detectam todos os tipos conhecidos de softwares mal-
intencionados.
Removem todos os tipos conhecidos de softwares mal-
intencionados, e
Protegem contra todos os tipos conhecidos de softwares
mal-intencionados.
Os exemplos de tipos de softwares mal-intencionados incluem
vrus, worms, trojans, spyware, adware e rootkits.
importante proteger contra TODOS os tipos e
formas de softwares mal-intencionados.

5.1.2 Para sistemas que normalmente
no so atacados por softwares mal-
intencionados, execute avaliaes
peridicas para identificar e avaliar a
evoluo de ameaas de malware a
fim de confirmar se tais sistemas
continuam a no precisar de software
de antivrus.
5.1.2Questione os funcionrios para verificar se a evoluo
de ameaas de malware monitorada e avaliada para
sistemas que normalmente no so atacados por softwares
mal-intencionados, a fim de confirmar se tais sistemas
continuam a no precisar de software de antivrus.
Tipicamente, mainframes, computadores de
mdio porte (como AS/400) e sistemas similares
podem no ser alvos ou afetados por malware no
momento. No entanto, as tendncias do setor
para softwares mal-intencionados podem mudar
rapidamente, por isso importante que as
organizaes estejam cientes de novos malwares
que possam afetar seus sistemas, por exemplo,
monitorando os avisos de segurana do
fornecedor e novos grupos de antivrus para
determinar se seus sistemas podem estar sob
ameaa de novos malwares.
As tendncias em softwares mal-intencionados
devem ser includas na identificao de novas
vulnerabilidades de segurana e os mtodos para
resolver novas tendncias devem ser
incorporados aos padres de configurao da
empresa e aos mecanismos de proteo,
conforme necessrio
5.2 Certifique-se de que todos os
mecanismos antivrus sejam mantidos
conforme segue:
So mantidos atualizados,
Executam varreduras peridicas
Geram logs de auditoria que so
mantidos conforme o Requisito 10.7
do PCI DSS.
5.2.a Analise as polticas e os procedimentos para verificar se
exigido que as definies e o software de antivrus sejam
mantidos atualizados.
Mesmo as melhores solues antivrus so
limitadas se no forem atualizadas com as mais
recentes atualizaes de segurana, arquivos de
assinatura ou protees contra malware.
Os logs de auditoria oferecem a capacidade de
monitorar as atividades do vrus e de malware e
as reaes contra malware. Dessa forma,
imprescindvel que as solues de malware sejam
configuradas de forma a gerar logs de auditoria e
esses logs devero ser gerenciados de acordo
com o Requisito 10.
5.2.b Analise as configuraes do antivrus, incluindo a
instalao principal do software para verificar se os
mecanismos antivrus esto:
Configurados para executar atualizaes automticas, e
Configurados para executar varreduras peridicas.
5.2.c Analise uma amostra dos componentes do sistema
incluindo todos os tipos de sistemas operacionais normalmente
afetados pelos softwares mal-intencionados, para verificar se:
O software de antivrus e as definies so atuais.
Executam varreduras peridicas.
5.2.d Analise as configuraes do antivrus, incluindo a
instalao principal do software e uma amostra dos
componentes do sistema para verificar se:
A gerao de log do software de antivrus est habilitada, e

Os logs so mantidos de acordo com o Requisito 10.7 do
PCI DSS.

5.3 Certifique-se de que os mecanismos
antivrus estejam funcionando
ativamente e no possam ser
desativados ou alterados pelos usurios,
a menos que seja especificamente
autorizado pelo gerenciamento com
base em cada caso por um perodo
limitado de tempo.
Observao: As solues de antivrus
podem ser temporariamente desativadas
apenas se houver necessidade tcnica
comprovada, conforme autorizado pelo
gerenciamento com base em cada caso.
Se a proteo de antivrus precisar ser
desativada por um motivo especfico,
isso deve ser formalmente autorizado.
Medidas adicionais de segurana
tambm podem precisar ser
implementadas pelo perodo de tempo
durante o qual a proteo de antivrus
no estiver ativa.
5.3.a Analise as configuraes do antivrus, incluindo a
componentes do sistema para verificar se o software de
antivrus est funcionando ativamente.
O antivrus executado continuamente e que
desativado para ser modificado proporcionar a
segurana persistente contra malware.
O uso de controles baseados na poltica em todos
os sistemas para garantir que as protees contra
malware no possam ser modificadas ou
desativadas ajudar a evitar que a fraqueza do
sistema seja aproveitada por software mal-
intencionado.
Medidas adicionais de segurana tambm podem
ser necessrias pelo perodo de tempo durante o
qual a proteo antivrus no estiver ativada, por
exemplo, desconectar o sistema desprotegido da
internet enquanto a proteo antivrus estiver
desativada e executar uma varredura completa
depois que ela for reativada.
5.3.b Analise as configuraes do antivrus, incluindo a
componentes do sistema para verificar se o software de
antivrus no pode ser desativado ou modificado pelos
usurios.
5.3.c Questione os funcionrios responsveis e observe os
processos para verificar se o software de antivrus no pode
ser desativado ou alterado pelos usurios, a menos que seja
especificamente autorizado pelo gerenciamento com base em
cada caso por um perodo limitado de tempo.
para proteger os sistemas contra
malware estejamdocumentados, em uso
envolvidas.
operacionais para proteger os sistemas contra malware esto:
Documentados,
Em uso, e
operacionais para garantir que os sistemas
estejam continuamente protegidos contra
malware.

Requisito 6: Desenvolver e manter sistemas e aplicativos seguros
Indivduos inescrupulosos usam as vulnerabilidades da segurana para obter acesso privilegiado aos sistemas. Muitas dessas vulnerabilidades
so solucionadas pelos patches de segurana disponibilizados pelos fornecedores, que devem ser instalados pelas entidades que gerenciam os
sistemas. Todos os sistemas devem contar com os patches de software adequados para proteger contra a explorao e o comprometimento dos
dados do portador do carto por indivduos e softwares mal-intencionados.
Observao: Patches de software adequados so aqueles patches que foram avaliados e testados de forma suficiente para determinar se os
patches no entram em conflito com as configuraes de segurana existentes. Para aplicativos desenvolvidos internamente, diversas
vulnerabilidades podem ser evitadas ao utilizar processos de desenvolvimento do sistema padro e tcnicas de codificao seguras.
6.1 Estabelea um processo para identificar
as vulnerabilidades de segurana, usando
fontes externas de boa reputao para
informaes de vulnerabilidades da
segurana e classifique uma escala de risco
(por exemplo, "alto", "mdio" ou "baixo") para
vulnerabilidades de segurana recentemente
descobertas.
Observao: As classificaes de risco
devem ser baseadas nas melhores prticas
do setor, bem como a considerao de
impacto potencial. Por exemplo, os critrios
para classificar as vulnerabilidades podem
incluir a considerao da marca da base
CVSS e/ou a classificao pelo fornecedor
e/ou os tipos de sistemas afetados.
Os mtodos para avaliar as vulnerabilidades
e classificar o nvel de risco variam baseados
no ambiente da organizao e na estratgia
de avaliao de risco. As classificaes de
risco devem, no mnimo, identificar todas as
vulnerabilidades consideradas de "alto risco"
ao ambiente. Alm da classificao de risco,
as vulnerabilidades podem ser consideradas
"crticas" se apresentarem uma ameaa
iminente ao ambiente, sistemas crticos de
impacto e/ou resultaria em comprometimento
potencial se no resolvidas. Exemplos de
sistemas crticos podem incluir sistemas de
6.1.a Analise as polticas e procedimentos para verificar se
os processos esto definidos para o que segue:
Para identificar novas vulnerabilidades da segurana
Para classificar uma escala de risco para as
vulnerabilidades que incluem identificao de todas as
vulnerabilidades de "alto risco" e "crticas".
Para usar fontes externas de boa reputao para obter
informaes sobre vulnerabilidade da segurana.
O objetivo deste requisito que as organizaes se
mantenham atualizadas quanto a novas
vulnerabilidades que podero interferir no sistema.
As fontes de informao de vulnerabilidades devem
ser confiveis e frequentemente incluem sites do
fornecedor, novos grupos do setor, lista de envios
ou RSS feeds.
Quando uma organizao identifica uma
vulnerabilidade que poder afetar seu ambiente, o
risco que essa vulnerabilidade representa deve ser
avaliado e classificado. A organizao deve ento,
ter um mtodo adequado para avaliar as
vulnerabilidades continuamente e classificar as
escalas de risco para estas vulnerabilidades. Isso
no acontece pela varredura ASV ou varredura de
vulnerabilidade interna, mas exige um processo
para monitorar ativamente as fontes do setor para
informaes de vulnerabilidade.
Classificar os riscos (por exemplo, como "altos",
"mdios" ou "baixos") permite que as organizaes
identifiquem, priorizem e encaminhem itens de
maior risco mais rapidamente e reduzam a
probabilidade de as vulnerabilidades que
representarem maior risco serem exploradas.
6.1.b Questione os funcionrios responsveis e observe os
processos para verificar se:
Novas vulnerabilidades da segurana so identificadas.
Uma escala de risco classificada para as
vulnerabilidades que incluem identificao de todas as
vulnerabilidades de "alto risco" e "crticas".
Os processos de identificao de novas vulnerabilidades
de segurana incluem o uso de fontes externas de boa
reputao para obteno de informaes sobre
vulnerabilidades.

segurana, dispositivos voltados ao pblico e
sistemas, bancos de dados e outros sistemas
que armazenam, processam ou transmitem
6.2 Certifique-se de que todos os
componentes do sistema e softwares estejam
protegidos de vulnerabilidades conhecidas
instalando os patches de segurana
aplicveis disponibilizados pelos
fornecedores. Instale patches de segurana
crticos em at um ms aps o lanamento.
Observao: Os patches de segurana
crtica devem ser identificados de acordo
com o processo de classificao de risco
definido no Requisito 6.1.
6.2.aAnalise as polticas e procedimentos relacionados
instalao dos patches de segurana para verificar se esto
definidos processos para:
Instalao de patches de segurana crticos
disponibilizados pelo fornecedor em at um ms aps o
lanamento.
Instalao de todos os patches de segurana aplicveis
disponibilizados pelo fornecedor dentro de um perodo
de tempo apropriado (por exemplo, dentro de trs
meses).
Existe um fluxo constante de invases usando
faanhas amplamente divulgadas, muitas vezes do
tipo "zero day" (uma invaso que se aproveita de
uma vulnerabilidade previamente desconhecida),
contra sistemas at ento seguros. Se os patches
mais recentes no forem implantados nos sistemas
crticos assim que possvel, um indivduo mal-
intencionado pode us-los para atacar ou desativar
um sistema ou obter acesso aos dados
confidenciais.
Priorizar os patches para a infraestrutura crtica
garante que os sistemas e dispositivos de alta
prioridade sejam protegidos contra vulnerabilidades
assim que o patch lanado. Considere priorizar as
instalaes do patch de forma que os patches de
segurana em sistemas crticos ou em risco sejam
instalados em at 30 dias e outros patches de
menor risco sejam instalados em 2 ou 3 meses.
Este requisito se aplica aos patches aplicveis para
todos os softwares instalados.
6.2.b Para obter uma amostra dos componentes do sistema
e dos softwares relacionados, compare a lista de patches
de segurana instalados em cada sistema com a lista de
patches de segurana mais recentes do fornecedor para
verificar o seguinte:
Os patches de segurana crticos disponibilizados pelo
fornecedor so instalados em at um ms aps o
lanamento.
Todos os patches de segurana aplicveis
disponibilizados pelo fornecedor so instalados em um
perodo de tempo apropriado (por exemplo, dentro de
trs meses).
6.3 Desenvolva aplicativos de software
internos e externos (incluindo acesso
administrativo pela Web aos aplicativos) com
segurana, conforme segue:
De acordo com o PCI DSS (por exemplo,
autenticao e logs seguros)
Baseados nos padres e/ou melhores
prticas do setor.
Incorporar segurana da informao ao
longo da vida til do desenvolvimento do
6.3.a Analise os processos de desenvolvimento do software
por escrito para verificar se os processos foram baseados
nos padres e/ou nas melhores prticas do setor.
Sem a incluso de uma proteo durante as fases
de definio de requisitos, design, anlise e teste do
desenvolvimento de software, as vulnerabilidades
de segurana podem ser apresentadas de forma
inadvertida ou mal-intencionada no ambiente de
produo.
Saber como os dados confidenciais so controlados
pelo aplicativo (incluindo quando so armazenados,
transmitidos e quando esto na memria) pode
ajudar a identificar onde os dados precisam ser
6.3.b Analise os processos de desenvolvimento do software
por escrito para verificar se a segurana da informao foi
includa durante o ciclo de vida.
6.3.c Analise os processos de desenvolvimento do software
por escrito para verificar se os aplicativos de software foram
desenvolvidos de acordo com o PCI DSS.

software.
Observao: isso se aplica a todos os
softwares desenvolvidos internamente, bem
como a softwares personalizados ou sob
encomenda desenvolvidos por terceiros.
6.3.d Questione os desenvolvedores do software para
verificar se processos por escrito de desenvolvimento do
software esto implementados.
protegidos.
6.3.1 Remova as contas de
desenvolvimento, teste e/ou
personalizados, IDs de usurio e senhas
antes que o aplicativo se torne ativo ou seja
lanado aos clientes.
6.3.1 Analise os procedimentos escritos do
desenvolvimento do software e questione os funcionrios
responsveis para verificar se as contas de pr-produo
e/ou de aplicativos personalizados, IDs de usurios e/ou
senhas so removidos antes de um aplicativo ser
produzido ou lanado aos clientes.
Contas de desenvolvimento, teste e/ou aplicativos
personalizados, IDs de usurios e senhas devem
ser removidos do cdigo de produo antes de o
aplicativo ser ativado ou liberado para os clientes,
pois esses itens podem fornecer informaes sobre
o funcionamento do aplicativo. A posse dessas
informaes pode facilitar o comprometimento do
aplicativo e dos dados relacionados do portador do
carto.

6.3.2 Revise o cdigo personalizado antes
da liberao para produo ou clientes a
fim de identificar qualquer possvel
vulnerabilidade no cdigo (usando
processos manuais ou automatizados) para
incluir ao menos o seguinte:
As alteraes dos cdigos so
analisadas por outras pessoas alm do
autor do cdigo e por pessoas que
esto cientes das tcnicas de anlise
dos cdigos e das prticas de
codificao seguras.
As revises de cdigo garantem que o
cdigo seja desenvolvido de acordo
com as diretrizes de codificao
seguras.
As correes adequadas so
implementadas antes da liberao.
Os resultados das anlises dos
cdigos so revisados e aprovados
pelo gerenciamento antes da
liberao.
6.3.2.a Analise os procedimentos escritos do
desenvolvimento do software e questione os funcionrios
responsveis para confirmar se todas as alteraes nos
cdigos dos aplicativos personalizados devem ser
revisadas (usando processos manuais ou automatizados),
conforme segue:
As alteraes dos cdigos so analisadas por outras
pessoas alm do autor que originou o cdigo e por
pessoas que esto cientes das tcnicas de anlise
dos cdigos e das prticas de codificao seguras.
As anlises dos cdigos asseguram que o cdigo foi
desenvolvido de acordo com as diretrizes de
codificao seguras (consulte o Requisito 6.5 do PCI
DSS).
As correes adequadas so implementadas antes
da liberao.
Os resultados das anlises dos cdigos so
revisados e aprovados pelo gerenciamento antes da
liberao.
As vulnerabilidades de segurana no cdigo
personalizado so comumente exploradas por
indivduos mal-intencionados para obter acesso a
uma rede e comprometer os dados do portador do
carto.
Um indivduo com conhecimento e experincia nas
tcnicas de anlise do cdigo deve estar envolvido
no processo de anlise. As anlises do cdigo
devem ser realizadas por algum que no seja o
desenvolvedor do cdigo a fim de permitir uma
reviso independente e objetiva. Processos ou
ferramentas automatizados tambm podem ser
usados ao invs de anlises manuais, mas pode ser
difcil ou at mesmo impossvel para uma
ferramenta automatizada identificar alguns
problemas do cdigo.
Corrigir os erros de codificao antes que o cdigo
seja enviado para produo ou distribudo para os
clientes evita que o mesmo exponha os ambientes a
possveis aproveitadores. Tambm muito mais
difcil de resolver um cdigo com defeito depois de
ele ser distribudo ou liberado para ambientes de
produo.
Incluir uma reviso formal e aprovao do
gerenciamento antes da liberao ajuda a garantir
que o cdigo seja aprovado e tenha sido
desenvolvido de acordo com as polticas e
procedimentos.

Observao: Este requisito referente s
anlises dos cdigos se aplica a todos os
cdigos personalizados (internos e voltados
ao pblico), como parte integrante do ciclo de
vida de desenvolvimento do sistema.
As anlises dos cdigos podem ser
realizadas por equipes internas instrudas ou
terceiros. Os aplicativos da Web voltados ao
pblico tambm esto sujeitos a controles
extras para abranger ameaas e
vulnerabilidades contnuas aps a
implementao, conforme definido no
Requisito 6.6 do PCI DSS.
6.3.2.b Selecione uma amostra de alteraes recentes
dos aplicativos personalizados e verifique se o cdigo do
aplicativo personalizado analisado de acordo com o item
6.3.2 acima.

6.4 Siga os procedimentos de controle de
alteraes para todas as alteraes nos
componentes do sistema. Esses processos
devem incluir o seguinte:
6.4 Analise as polticas e os procedimentos para verificar se
o seguinte est definido:
Os ambientes de desenvolvimento/teste so separados
do ambiente de produo, com controle de acesso
implementado para executar a separao.
Uma separao das tarefas entre a equipe atribuda aos
ambientes de desenvolvimento/teste e a atribuda ao
ambiente de produo.
Os dados de produo (PANs ativos) no so usados
para testes ou desenvolvimento.
Os dados e as contas de teste so removidos antes que
o sistema de produo se torne ativo.
Os procedimentos de controle de alteraes ligados
implementao de patches de segurana e s
modificaes esto documentados.
Sem controles de alterao adequadamente
documentados e implementados, os recursos de
segurana podem ser omitidos sem ou com
inteno ou ainda tornados inoperveis e podem
ocorrer irregularidades no processamento ou pode
ser introduzido um cdigo mal-intencionado.
6.4.1 Separe os ambientes de
teste/desenvolvimento do ambiente de
produo e reforce a separao com
controle de acesso.
6.4.1.a Analise a documentao de rede e as
configuraes do dispositivo de rede para verificar se os
ambientes de desenvolvimento/teste so separados do
ambiente de produo.
Devido mutao constante dos ambientes de
desenvolvimento e teste, estes tendem a ser menos
seguros do que o ambiente de produo. Sem a
separao adequada entre os ambientes, possvel
que o ambiente de produo e os dados do portador
do carto sejam comprometidos devido s
configuraes de segurana menos rigorosas e
possveis vulnerabilidades em um ambiente de teste
ou desenvolvimento.
6.4.1.b Analise os ajustes dos controles de acesso para
verificar se estes esto implementados para forar a
separao entre os ambientes de teste/desenvolvimento e
os ambientes de produo.

6.4.2 Separao dos deveres entre os
ambientes de desenvolvimento/teste e de
produo
6.4.2 Observe os processos e questione os funcionrios
designados para os ambientes de teste/desenvolvimento
e os designados para os ambientes de produo para
verificar se a separao dos deveres foi implementada
entre eles.
Reduzir o nmero de pessoas com acesso ao
ambiente de produo e aos dados do portador do
carto reduz os riscos e ajuda a garantir que o
acesso seja limitado aos indivduos com
necessidade comercial de saber.
O objetivo deste requisito separar as funes de
desenvolvimento e teste das funes de produo.
Por exemplo, um desenvolvedor poder utilizar uma
conta com nvel de administrador com privilgios
elevados no ambiente de desenvolvimento e possuir
uma conta separada com acesso de nvel de
usurio ao ambiente de produo.
6.4.3 Os dados de produo (PANs ativos)
no so usados para testes ou
desenvolvimento
6.4.3.a Observe os processos de teste e questione os
funcionrios para verificar se os procedimentos esto
implementados para garantir que os dados de produo
(PANs ativos) no sejam usados para testes ou
desenvolvimento.
Os controles de segurana normalmente no so
to rgidos no ambiente de desenvolvimento ou de
teste. O uso de dados de produo d aos
indivduos mal-intencionados a oportunidade de
ganhar acesso no autorizado aos dados de
produo (dados do portador do carto).
6.4.3.b Analise uma amostra dos dados de teste para
verificar se os dados de produo (PANs ativos) no so
usados para testes ou desenvolvimento.
6.4.4 Remoo dos dados de teste e
contas antes que os sistemas de produo
se tornem ativos
6.4.4.a Observe os processos de teste e questione os
funcionrios para verificar se os dados e as contas de
teste so removidos antes que o sistema de produo se
torne ativo.
Dados e contas de teste devem ser removidos do
cdigo da produo antes de o aplicativo ser
ativado, pois esses itens podem fornecer
informaes sobre o funcionamento do aplicativo ou
do sistema. A posse dessas informaes pode
facilitar o comprometimento do sistema e dos dados
relacionados do portador do carto.
6.4.4.b Analise uma amostra de dados e contas dos
sistemas de produo recentemente instalados ou
atualizados para verificar se estes so removidos antes
que o sistema se torne ativo.

6.4.5 Os procedimentos de controle de
alteraes para a implementao de
patches de segurana e modificaes de
software devem incluir o seguinte:
6.4.5.a Analise os procedimentos de controle de
alteraes ligados implementao de patches de
segurana e s modificaes do software e verifique se os
procedimentos esto definidos para:
Documentao de impacto
Aprovao documentada de alterao pelas partes
autorizadas
Teste de funcionalidade para verificar se a alterao
no tem impacto adverso sobre a segurana do
sistema
Procedimentos de reverso
Se no for adequadamente controlado, o impacto
das atualizaes do software e patches de
segurana pode no ser realizado por completo e
pode ter consequncias inesperadas.
6.4.5.b Para obter uma amostra dos componentes do
sistema, questione os funcionrios responsveis para
determinar os patches de segurana/alteraes recentes.
Rastreie essas alteraes com a documentao de
controle de alterao relacionada. Para cada alterao
analisada, desempenhe o seguinte:
6.4.5.1 Documentao de impacto. 6.4.5.1 Verifique se a documentao de impacto est
includa na documentao de controle de alteraes
para cada alterao exemplificada.
O impacto da alterao deve ser documentado de
forma que todas as partes afetadas possam
planejar adequadamente quaisquer alteraes de
processamento.
6.4.5.2 Aprovao documentada de
alterao pelas partes autorizadas.
6.4.5.2 Verifique se a aprovao documentada por
partes autorizadas est presente para cada alterao
exemplificada.
A aprovao por partes autorizadas indica que a
alterao legtima e que a alterao aprovada foi
sancionada pela organizao.
6.4.5.3 Teste de funcionalidade para
verificar se a alterao no tem impacto
adverso sobre a segurana do sistema.
6.4.5.3.a Para cada alterao exemplificada, verifique se
o teste de funcionalidade foi realizado para verificar se a
alterao no tem impacto adverso sobre a segurana
do sistema.
Devero ser realizados testes rigorosos para
verificar se a segurana do ambiente no se reduz
ao ser implantada uma alterao. O teste dever
validar se todos os controles de segurana
existentes permaneam no lugar, sejam
substitudos por controles igualmente rigorosos ou
sejam reforados aps alguma alterao no
ambiente.
6.4.5.3.b Para alteraes de cdigo personalizado,
verifique se todas as atualizaes foram testadas para
estarem de acordo com o Requisito 6.5 do PCI DSS
antes de serem implementadas na produo.

6.4.5.4 Procedimentos de reverso. 6.4.5.4 Verifique se os procedimentos de reverso foram
preparados para cada alterao exemplificada.
Para cada alterao, deve haver procedimentos de
reverso documentados para o caso de falhas na
alterao ou efeitos adversos na segurana de um
aplicativo ou sistema, a fim de permitir que o
sistema seja restaurado ao seu estado anterior.
6.5 Trate as vulnerabilidades de codificao
comuns nos processos de desenvolvimento
do software conforme segue:
Treine os desenvolvedores sobre
tcnicas seguras de codificao, incluindo
como evitar vulnerabilidades comuns de
codificao e compreendendo como os
dados confidenciais so controlados na
memria.
Desenvolva aplicativos baseados nas
diretrizes de cdigo seguro.
Observao: As vulnerabilidades listadas
nos itens 6.5.1 a 6.5.10 estavam atualizadas
de acordo com as melhores prticas do setor,
quando esta verso do PCI DSS foi
publicada. No entanto, conforme as melhores
prticas do setor para o gerenciamento de
vulnerabilidades so atualizadas (por
exemplo o Guia

OWASP, SANS CWE Top
25, CERT Secure Coding, etc.), as melhores
prticas atuais precisam ser usadas para
estes requisitos.
6.5.a Analise as polticas e procedimentos de
desenvolvimento de software para verificar se exigido
treinamento em tcnicas de codificao seguras para
desenvolvedores, com base nas melhores prticas e
diretrizes do setor.
A camada do aplicativo de alto risco e pode ser
tida como alvo por ameaas internas e externas.
Os requisitos 6.5.1 a 6.5.10 so os controles
mnimos que devem ser implementados e as
organizaes devem incorporar as prticas seguras
de codificao relevantes conforme aplicvel
tecnologia especfica em seu ambiente.
Os desenvolvedores de aplicativos devem ser
treinados adequadamente para identificar e resolver
problemas relacionados a estas (e outras)
vulnerabilidades de codificao comuns. Uma
equipe com conhecimento sobre as orientaes
seguras de codificao deve minimizar o nmero de
vulnerabilidades de segurana introduzidas por
meio de ms prticas de codificao. O treinamento
para os desenvolvedores pode ser ministrado no
local ou por terceiros e deve ser aplicvel
tecnologia utilizada.
Todas as alteraes de prticas de decodificao
aceitas pelo setor, as prticas de decodificao
organizacionais e o treinamento de
desenvolvedores devem ser atualizados igualmente
para lidar com novas ameaas, por exemplo,
invases relacionadas limpeza de memria.
As vulnerabilidades identificadas no 6.5.1 at o
6.5.10 oferecem uma linha de base mnima. de
escolha da organizao permanecer atualizada com
as tendncias de vulnerabilidades e incorporar as
medidas apropriadas em suas prticas seguras de
codificao.
6.5.b Questione alguns desenvolvedores para verificar se
eles esto instrudos sobre as tcnicas de codificao
seguras.
6.5.c Consulte os registros de treinamento para verificar se
os desenvolvedores de software receberam treinamento
sobre tcnicas seguras de codificao, incluindo como
evitar vulnerabilidades comuns de codificao e
compreendendo como os dados confidenciais so
controlados na memria.
6.5.d. Verifique se esto implementados processos para
proteger os aplicativos contra, pelo menos, as seguintes
vulnerabilidades:

Observao: Os requisitos 6.5.1 a 6.5.6 abaixo se aplicam a todos os aplicativos (internos ou externos).
6.5.1 Falhas na injeo, particularmente na
injeo SQL. Tambm considere as falhas
de injeo OS Command Injection, LDAP e
Xpath, assim como outras falhas.
6.5.1 Analise as polticas e procedimentos de
desenvolvimento de software e questione os funcionrios
responsveis para verificar se as falhas de injeo so
resolvidas pelas tcnicas de codificao que incluem:
Validar a entrada para verificar se os dados do
usurio no podem modificar o significado dos
comandos e das consultas.
Utilizar consultas parametrizadas.
As falhas de injeo, principalmente de injeo de
SQL, so um mtodo comumente utilizado em
aplicativos comprometidos. A injeo ocorre quando
dados fornecidos pelo usurio so enviados para
um intrprete como parte de um comando ou
consulta. Os dados hostis do invasor enganam o
intrprete para executar comandos no planejados
ou para alterar os dados e permitem que o invasor
invada os componentes dentro da rede por meio do
aplicativo, a fim de iniciar invases como
sobrecargas do buffer, ou para revelar tanto
informaes confidenciais quando funcionalidades
no aplicativo do servidor.
As informaes devem ser validadas antes de
serem enviadas para o aplicativo, por exemplo, ao
verificar todos os caracteres alfabticos, mistura de
caracteres alfabticos e numricos, etc.
6.5.2 Sobrecargas do buffer 6.5.2 Analise as polticas e procedimentos de
responsveis para verificar se as sobrecargas de buffer
so resolvidas pelas tcnicas de codificao que incluem:
Validar os limites do buffer.
Truncar as strings de entrada.
As sobrecargas de buffer ocorrem quando um
aplicativo no possui uma verificao de limites
adequada em seu espao de buffer. Isto pode fazer
com que as informaes no buffer sejam
empurradas para o espao da memria do buffer e
o espao da memria executvel. Quando isso
ocorre, o invasor consegue inserir um cdigo mal-
intencionado no final do buffer e envie por push este
cdigo para o espao de memria executvel ao
provocar sobrecarga de buffer. O cdigo mal-
intencionado ento executado e com frequncia
permite que o invasor acesse remotamente o
aplicativo e/ou o sistema infectado.

6.5.3 Armazenamento criptogrfico no
seguro
responsveis para verificar se o armazenamento
criptogrfico no seguro direcionado pelas tcnicas de
codificao que:
Evita falhas criptogrficas.
Utiliza chaves e algoritmos de criptografia forte.
Os aplicativos que no utilizam recursos de
criptografia forte de maneira adequada para
armazenar dados correm um risco maior de ficarem
comprometidos e de expor as credenciais de
autenticao e/ou os dados do portador do carto.
Caso um invasor consiga explorar os processos
criptogrficos, ele poder obter acesso de texto
simples aos dados criptografados.
6.5.4 Comunicaes no seguras 6.5.4 Analise as polticas e procedimentos de
responsveis para verificar se as comunicaes no
seguras so direcionadas pelas tcnicas de codificao
que autenticam e criptografam corretamente todas as
comunicaes confidenciais.
Os aplicativos que no criptografarem
adequadamente o trfego de rede utilizando
criptografia forte correm um risco maior de ficarem
comprometidos e de expor os dados do portador do
carto. Se o invasor conseguir explorar os
processos criptografados, poder obter controle de
um aplicativo ou at mesmo obter acesso de texto
no criptografado a dados criptografados.
6.5.5 Tratamento incorreto de erros 6.5.5 Analise as polticas e procedimentos de
responsveis para verificar se o tratamento incorreto de
erros direcionado pelas tcnicas de codificao que no
vazam informaes por meio de mensagens de erro (por
exemplo, retornando detalhes de erros genricos ao invs
de erros especficos).
Os aplicativos podem, de forma no intencional,
vazar informaes sobre sua configurao,
trabalhos internos ou expor informaes
privilegiadas por meio de mtodos de tratamento de
erros. Os invasores usam esse ponto fraco para
roubar dados confidenciais ou para comprometer o
sistema como um todo. Se um indivduo mal-
intencionado puder criar erros que o aplicativo no
consegue manusear corretamente, eles podem
obter informaes detalhadas do sistema, criar
interrupes de negao de servio, causar falhas
de segurana ou criar problemas no servidor. Por
exemplo, a mensagem senha incorretainforma ao
invasor que o ID de usurio fornecido est correto e
que ele deve concentrar os esforos somente na
senha. Use mensagens de erro mais genricas,
como os dados no puderam ser verificados".

6.5.6 Todas as vulnerabilidades de "alto
risco" identificadas no processo de
identificao de vulnerabilidade (conforme
definido no Requisito 6.1 do PCI DSS).
6.5.6Analise as polticas e procedimentos de
responsveis para verificar se as tcnicas de codificao
resolvem qualquer vulnerabilidade de "alto risco" que
possa afetar o aplicativo, conforme identificado no
Requisito 6.1 do PCI DSS.
Todas as vulnerabilidades identificadas pelo
processo de classificao de risco de
vulnerabilidade de uma organizao (definido no
Requisito 6.1) como sendo de "alto risco" e que
possam afetar o aplicativo devem ser identificadas e
resolvidas durante o desenvolvimento do aplicativo.
Observao: Os Requisitos 6.5.7 a 6.5.10 abaixo se aplicam a aplicativos da Web e em interfaces de
aplicativos
(internos ou externos):
Os aplicativos da Web, tanto internos quanto
externos (pblicos), possuem riscos de segurana
exclusivos com base em sua arquitetura e sua
relativa facilidade em apresentar comprometimento.
6.5.7 Script intersite (XSS) 6.5.7Analise as polticas e procedimentos de
responsveis para verificar se o script intersite (XSS)
direcionado pelas tcnicas de codificao que incluem
Validar todos os parmetros antes da incluso
Utilizar sada de contexto confidencial.
Ocorrem falhas no XSS sempre que o aplicativo
coletar os dados fornecidos pelo usurio e envi-los
para um navegador sem primeiro validar ou
codificar esse contedo. O XSS permite que os
invasores executem o script no navegador da
vtima, que pode se apoderar de sesses de
usurios, desfigurar sites, possivelmente introduzir
worms, etc.

6.5.8 Controle de acesso inadequado
(como referncias diretas no seguras a
objetos, falhas em restringir o acesso a
URLs, diretrios transversais e falhas em
restringir o acesso do usurio s funes).
responsveis para verificar se o controle de acesso
incorreto (como referncias diretas no seguras a objetos,
falha em restringir o acesso a URLs e diretrios
transversais) direcionado pelas tcnicas de codificao
que incluem:
Autenticao adequada dos usurios
Limpar a entrada
No expor referncias de objetos internos aos
usurios
As interfaces do usurio no permitem o acesso a
funes no autorizadas.
Uma referncia de objeto direto ocorre quando o
desenvolvedor expe uma referncia a um objeto
de implementao interna, como arquivo, diretrio,
registro de banco de dados ou chave, como um
URL ou forma de parmetro. Os invasores podem
manipular essas referncias para acessar outros
objetos sem autorizao.
Force constantemente o controle de acesso na
camada de apresentao e na lgica de negcios
para todos os URLs. Muitas vezes um aplicativo s
protege os recursos confidenciais ao evitar a
exibio de links ou URLs para usurios no
autorizados. Os invasores podem usar esse ponto
fraco para acessar e executar operaes no
autorizadas, acessando diretamente esses URLs.
Um invasor poder ser capaz de enumerar e
navegar pela estrutura do diretrio de um site
(diretrio transversal), obtendo acesso a
informaes no autorizadas e descobrindo o
funcionamento do site para explorao futura.
Se as interfaces do usurio permitirem o acesso a
funes no autorizadas, este acesso pode fazer
com que indivduos no autorizados obtenham
acesso a credenciais privilegiadas ou aos dados do
portador do carto. Apenas usurios autorizados
devem ter permisso para acessar as referncias
diretas de objetos a recursos confidenciais. Limitar o
acesso aos recursos de dados ajudar a evitar que
os dados do portador do carto sejam apresentados
a recursos no autorizados.
6.5.9 Solicitao intersite forjada (CSRF). 6.5.9Analise as polticas e procedimentos de
responsveis para verificar se a solicitao intersite
forjada (CSRF) direcionada pelas tcnicas de
codificao que garantem que os aplicativos no contem
com tokens e credenciais de autorizao
automaticamente enviados pelos navegadores.
Um invaso de CSRF fora o navegador da vtima
logada a enviar uma solicitao pr-autenticada a
um aplicativo da Web vulnervel, que ento
possibilita ao invasor realizar qualquer operao de
modificao do status que a vtima tenha
autorizao para realizar (como atualizar detalhes
da conta, fazer aquisies ou at mesmo autenticar
ao aplicativo).

6.5.10 Autenticao quebrada e
gerenciamento de sesso
Observao: O requisito 6.5.10 ser
considerado uma das melhores prticas at
30 de junho de 2015 quando passar a ser
um requisito.
responsveis para verificar se a autenticao quebrada e
o gerenciamento de sesso so resolvidos pelas tcnicas
de codificao que comumente incluem:
Marcar os tokens de sesso (por exemplo, cookies)
como "seguro"
No expor os IDs de sesso no URL
Incorporar perodos de tempo apropriados e rotao
de IDs de sesso depois de efetuar logon com
sucesso.
A autenticao segura e gerenciamento de sesso
evita que indivduos no autorizados comprometam
as credenciais, chaves ou tokens de sesso
legtimos da conta, o que pode permitir que o
invasor assuma a identidade de um usurio
autorizado.

6.6 Para aplicativos da Web voltados ao
pblico, trate novas ameaas e
vulnerabilidades continuamente e assegure
que esses aplicativos estejam protegidos
contra invases conhecidos por meio de
qualquer um dos mtodos a seguir:
Analisar os aplicativos da Web voltados
ao pblico por meio de ferramentas ou
mtodos manuais ou automticos de
avaliao de segurana das
vulnerabilidades dos aplicativos, pelo
menos anualmente e aps quaisquer
alteraes
Observao: Esta avaliao no igual
s varreduras de vulnerabilidades
realizadas para o Requisito 11.2.
Instalar uma soluo tcnica
automatizada que detecte e previna
invases baseadas na Web (por exemplo,
um firewall de aplicativo na Web) na
frente de aplicativos da Web voltados
para o pblico, para verificar
continuamente todo o trfego.
6.6Para aplicativos da Web voltados ao pblico, certifique-
se de que qualquer um dos mtodos a seguir esteja
implementado conforme se segue:
Analise os processos documentados, questione os
funcionrios e analise os registros de avaliao de
segurana do aplicativo para verificar se os aplicativos
da Web voltados ao pblico so analisados (usando
ferramentas ou mtodos manuais ou automatizados de
avaliao de segurana das vulnerabilidades) conforme
segue:
- Pelo menos uma vez ao ano
- Aps quaisquer alteraes
- Por meio de uma empresa especializada na
segurana de aplicativos
- Se, pelo menos, todas as vulnerabilidades no
Requisito 6.5 esto includas na avaliao
- Se todas as vulnerabilidades so corrigidas
- Se o aplicativo reavaliado aps as correes.
Analise os ajustes da configurao do sistema e
questione os funcionrios para verificar se uma soluo
tcnica automatizada que detecte e previna invases
baseadas na Web (por exemplo, um firewall de
aplicativo na Web) seja implementada conforme segue:
- Est situada diante de aplicativos da Web voltados
ao pblico para detectar e prevenir invases
baseadas na Web.
- Est funcionando ativamente e atualizada
conforme aplicvel.
- Est gerando logs de auditoria.
- Est configurada para bloquear invases baseadas
na Web ou gerar um alerta.
Os aplicativos da Web voltados ao pblico so alvos
principais de invasores e se no estiverem bem
codificados, proporcionam caminho fcil para que
os invasores obtenham acesso aos dados e
sistemas confidenciais. O requisito para analisar
aplicativos ou instalar firewalls de aplicativos da
Web destina-se a reduzir o nmero de
comprometimentos em aplicativos da Web devido
m codificao ou ms prticas de gerenciamento
do aplicativo.
Ferramentas ou mtodos de avaliao da
segurana de vulnerabilidade manual ou
automatizada analisam e/ou testam o aplicativo
para identificar vulnerabilidades
Firewalls de aplicativo da Web filtram e
bloqueiam trfego no essencial na camada do
aplicativo. Utilizado em conjunto com um firewall
com base em rede, um firewall de aplicativo da
Web configurado corretamente evita invases
na camada de aplicativos caso estes estejam
codificados ou configurados incorretamente.
Observao: Uma empresa especializada na
segurana de aplicativos pode ser uma empresa
terceirizada ou uma empresa interna, desde que os
analisadores sejam especializados na segurana de
aplicativos e possam demonstrar que no
dependem da equipe de desenvolvimento.

para desenvolver e manter os sistemas e
aplicativos estejamdocumentados, em uso e
conhecidos por todas as partes envolvidas.
6.7 Analise a documentao e questione os funcionrios
para verificar se as polticas de segurana e procedimentos
operacionais para desenvolver e manter os sistemas e
aplicativos esto:
Documentados,
Em uso, e
Os funcionrios precisam estar cientes e seguir as
polticas de segurana e os procedimentos
operacionais para garantir que os sistemas e
aplicativos sejam desenvolvidos com segurana e
continuamente protegidos contra vulnerabilidades.

Implemente medidas rigorosas de controle de acesso
Requisito 7: Restrinja o acesso aos dados do portador do carto de acordo com a necessidade de conhecimento para
o negcio
Para assegurar que os dados crticos possam ser acessados somente por uma equipe autorizada, os sistemas e processos devem estar
implementados para limitar o acesso com base na necessidade de divulgao e de acordo com as responsabilidades da funo.
A necessidade de divulgao quando os direitos de acesso so concedidos somente ao menor nmero possvel de dados e privilgios
necessrios para realizar um trabalho.
7.1 Limite o acesso aos
componentes do sistema e aos
dados do portador do carto
somente quelas pessoas cuja
funo requer tal acesso.
7.1 Analise a poltica por escrito para o controle de acesso e
verifique se a poltica incorpora os requisitos 7.1.1 a 7.1.4
conforme segue:
Definir necessidades de acesso e atribuies especiais para
cada funo
Restrio de acesso a IDs de usurios privilegiados ao menor
nmero de privilgios necessrios para desempenhar as
responsabilidades da funo
A concesso do acesso se baseia na classificao e na
atribuio da funo da equipe individual
Aprovao documentada (eletronicamente ou por escrito)
pelas partes autorizadas a todo o acesso, incluindo lista de
privilgios especficos aprovados.
Quanto mais pessoas tiverem acesso aos dados do
portador do carto, mais risco haver de que a
conta do usurio seja utilizada indevidamente.
Limitar o acesso s pessoas com motivo corporativo
legtimo para ter esse acesso ajuda a organizao a
evitar o mau uso dos dados do portador do carto
devido inexperincia ou ms intenes.
7.1.1 Defina as necessidades de
acesso para cada funo,
incluindo:
Componentes do sistema e
recursos de dados que cada
funo precisa acessar para
realizar seu trabalho
O nvel de privilgio
necessrio (por exemplo,
usurio, administrador, etc.)
para acessar os recursos.
7.1.1 Selecione uma amostra de funes e verifique se as
necessidades de acesso para cada funo esto definidas e se
incluem:
Componentes do sistema e recursos de dados que cada
funo precisa acessar para realizar seu trabalho
Identificao do privilgio necessrio para cada funo
realizar seu trabalho.
Para limitar o acesso aos dados do portador do
carto para apenas os indivduos que precisam
deste acesso, primeiro necessrio definir as
necessidades de acesso para cada funo (por
exemplo, administrador do sistema, equipe da
central de atendimento, balconista), os
sistemas/dispositivos/dados que cada funo
precisa acessar e o nvel de privilgio que cada
funo precisa para desempenhar efetivamente as
tarefas atribudas. Uma vez que as funes e
necessidades de acesso correspondentes
estiverem definidas, os indivduos tero o direito de
acesso.

7.1.2 Restrinja o acesso a IDs de
usurios privilegiados ao menor
nmero de privilgios necessrios
para desempenhar as
responsabilidades da funo.
7.1.2.a Questione os funcionrios responsveis por permitir o
acesso para verificar se o acesso a IDs de usurios privilegiados
:
Permitido apenas s funes que requerem
especificamente tal acesso privilegiado
Restritos ao menor nmero de privilgios necessrios para
o desempenho das responsabilidades da funo.
Ao atribuir IDs privilegiados, importante atribuir
aos indivduos apenas os privilgios que eles
precisam para desempenhar seu trabalho (o
"mnimo de privilgios"). Por exemplo, o
administrador do bando de dados ou do backup no
deve ter os mesmos privilgios que o administrador
dos sistemas como um todo.
7.1.2.b Selecione uma amostra de IDs de usurio com acesso
privilegiado e questione a equipe de gerenciamento responsvel
para verificar se os privilgios concedidos so:
Necessrios para a funo daquela pessoa
Restritos ao menor nmero de privilgios necessrios para
o desempenho das responsabilidades da funo.
Conceder o mnimo de privilgios ajuda a evitar que
usurios sem conhecimento suficiente sobre o
aplicativo alterem incorretamente ou acidentalmente
a configurao do aplicativo ou alterem seus ajustes
de segurana. Executar o mnimo de privilgios
tambm ajuda a minimizar os danos de uma pessoa
no autorizada obter acesso ao ID do usurio.
7.1.3 Conceda acesso com base
na classificao e na atribuio da
funo de cada indivduo da
equipe.
7.1.3 Selecione uma amostra de IDs de usurio e questione a
equipe de gerenciamento responsvel para verificar se os
privilgios concedidos baseiam-se na classificao e atribuio
da funo do indivduo.
Quando as necessidades estiverem definidas para
as funes do usurio (conforme o requisito 7.1.1
do PCI DSS), fcil conceder o acesso aos
indivduos de acordo com sua funo e
classificao de seu trabalho utilizando as funes
j criadas.
7.1.4 Solicite aprovao
documentada por partes
autorizadas especificando os
privilgios exigidos.
7.1.4 Selecione uma amostra dos IDs de usurio e compare com
as aprovaes documentadas para verificar se:
Existe aprovao documentada para os privilgios
atribudos
A aprovao foi realizada pelas partes autorizadas
Os privilgios especificados correspondem com as funes
atribudas ao indivduo.
A aprovao documentada (por exemplo, por
escrito ou eletronicamente) garante que as pessoas
com acesso e privilgios estejam cientes e
autorizadas pelo gerenciamento e que seu acesso
seja necessrio para suas funes.

7.2 Estabelea um sistema de
controle de acesso para os
componentes do sistema que
restrinja o acesso com base na
necessidade de conhecimento do
usurio e que esteja configurado
para "recusar todos", a menos que
seja permitido de forma especfica.
Esse sistema de controle de acesso
deve incluir o seguinte:
7.2Analise as configuraes do sistema e a documentao do
fornecedor para verificar se um sistema de controle de acesso foi
implementado, conforme segue:
Sem um mecanismo para restringir o acesso com
base na necessidade de conhecimento do usurio,
este pode sem querer receber acesso aos dados do
portador do carto. Um sistema de controle de
acesso automatiza o processo de restringir o
acesso e atribuir privilgios. Alm disso, uma
configurao padro "recusar todos" garante que
ningum tenha acesso at ou a menos que uma
regra seja estabelecida especificamente
concedendo este acesso.
Observao: Alguns sistemas de controle de
acesso so definidos, como padro, como permitir
todos, permitindo, portanto, o acesso a menos
que/at que uma norma seja redigida para recus-lo
de forma especfica.
7.2.1 Abrangncia de todos os
componentes do sistema
7.2.1 Confirme se os sistemas de controle de acesso foram
implementados em todos os componentes do sistema.
7.2.2 A concesso dos privilgios
aos indivduos est baseada na
classificao e na atribuio da
funo.
7.2.2 Confirme se os sistemas de controle de acesso esto
configurados para impor os privilgios concedidos s pessoas
com base na classificao e na atribuio da funo.
7.2.3 Configurao padro
recusar todos.
7.2.3 Confirme se os sistemas de controle de acesso tm uma
configurao padro recusar todos.
7.3 Certifique-se de que as polticas
de segurana e procedimentos
operacionais para restringir o
acesso aos dados do portador do
carto estejam documentados, em
uso e conhecidos por todas as
partes envolvidas.
operacionais para restringir o acesso aos dados do portador do
carto esto:
Documentados,
Em uso, e
operacionais para garantir que o acesso seja
continuamente controlado e com base na
necessidade de conhecimento e no mnimo de
privilgios.

Requisito 8: Identifique e autentique o acesso aos componentes do sistema
Atribuir uma identificao exclusiva (ID) a cada pessoa com acesso assegura que cada indivduo seja exclusivamente responsvel pelas suas
aes. Quando tal responsabilidade estiver em vigor, as aes desempenhadas nos dados e sistemas crticos sero realizadas e podem ser
rastreadas, por usurios e processos conhecidos e autorizados.
A efetividade de uma senha largamente determinada pelo projeto e implementao do sistema de autenticao, particularmente, com que
frequncia um invasor pode fazer tentativas de senha e os mtodos de segurana para proteger as senhas do usurio no ponto de entrada,
durante a transmisso e enquanto estiver armazenada.
Observao: Esses requisitos so aplicveis a todas as contas, inclusive contas de pontos de venda com capacidades administrativas e todas
as contas usadas para visualizar ou acessar os dados do portador do carto ou acessar sistemas com dados do portador do carto. Isso inclui as
contas usadas por fornecedores e outros terceiros (por exemplo, para suporte e manuteno).
No entanto, os requisitos 8.1.1, 8.2, 8.5, 8.2.3 at o 8.2.5 e o 8.1.6 at o 8.1.8 no tm por objetivo serem aplicados a contas de usurio em um
aplicativo de pagamento de um ponto de venda que possua acesso somente a um nmero de carto por vez para facilitar a transao nica
(como contas de caixa).
8.1 Defina e implemente polticas e
procedimentos para garantir o
gerenciamento adequado da
identificao do usurio para usurios
que no sejam clientes e
administradores em todos os
componentes do sistema, conforme
segue:
8.1.a Revise os procedimentos e confirme se eles definem
processos para cada um dos itens abaixo em 8.1.1 at 8.1.8
Ao garantir que todos os usurios sejam
individualmente identificados, em vez de usar um ID
para vrios funcionrios, uma organizao
consegue manter a responsabilidade individual
pelas aes e uma trilha de auditoria eficaz por
funcionrio. Isso ajudar a apressar a resoluo e a
conteno de problemas quando ocorrer mau uso
ou tentativa mal-intencionada.
8.1.b Verifique se os processos foram implementados para o
gerenciamento de identificao do usurio, realizando o
seguinte:
8.1.1Atribua a todos os usurios um ID
exclusivo antes de permitir que eles
acessem os componentes do sistema
ou os dados do portador do carto.
8.1.1Questione a equipe administrativa para confirmar se
todos os usurios recebem um ID exclusivo para acessar os
componentes do sistema ou os dados do portador do carto.
8.1.2Controle o acrscimo, a excluso
e a modificao dos IDs do usurio,
credenciais e outros objetos do
responsvel pela identificao.
8.1.2 Para obter uma amostra dos IDs de usurios
privilegiados e IDs de usurios gerais, analise as autorizaes
associadas e observe os ajustes do sistema para verificar se
cada ID do usurio e ID do usurio privilegiado foi
implementado apenas com os privilgios especificados na
aprovao documentada.
Para garantir que as contas de usurio com acesso
aos sistemas so todas usurios vlidos e
reconhecidos, processos rigorosos devem controlar
todas as modificaes nos IDs de usurio e outras
credenciais de autenticao, incluindo adicionar
novos e modificar ou excluir os existentes.

8.1.3 Revogue imediatamente o
acesso de quaisquer usurios
desligados da empresa.
8.1.3.a Selecione uma amostra de funcionrios desligados da
empresa nos ltimos seis meses e analise as listas de acesso
dos usurios atuais,tanto para o acesso remoto quanto o local,
a fim de verificar se seus IDs foram desativados ou removidos
das listas de acesso.
Se um funcionrio sair da empresa e ainda tiver
acesso rede por meio de sua conta de usurio,
pode ocorrer um acesso desnecessrio ou mal-
intencionado aos dados do portador do carto, pelo
antigo funcionrio ou por um usurio mal-
intencionado que se aproveite da conta antiga e no
utilizada. Para prevenir o acesso no autorizado, as
credenciais do usurio e outros mtodos de
autenticao precisam ser revogados
imediatamente (assim que possvel) sada do
funcionrio.
8.1.3.b Verifique se todos os mtodos fsicos de autenticao
(como smart cards, tokens, etc.) tenham sido devolvidos ou
desativados.
8.1.4 Remover/desativar as contas
inativas dos usurios pelo menos a
cada 90 dias.
8.1.4Observe as contas do usurio para verificar se as contas
inativas por mais de 90 dias so removidas ou desativadas.
As contas no usadas regularmente so alvos
frequentes de invases, pois menos provvel que
qualquer alterao (como uma senha alterada) seja
notada. Desse modo, estas contas podem ser
aproveitadas mais facilmente e usadas para
acessar os dados do portador do carto.
8.1.5 Controle as IDs usadas pelos
fornecedores para acessar, suportar
ou manter os componentes do sistema
por meio de acesso remoto, conforme
segue:
Ativar apenas durante o perodo
necessrio e desativar quando
no estiverem em uso.
Monitorar quando estiverem em
uso.
8.1.5.a Questione os funcionrios e observe os processos
para controlar as contas usadas pelos fornecedores para
acessar, suportar ou manter os componentes do sistema para
verificar se as contas usadas por fornecedores por meio de
acesso remoto so:
Desativadas quando no estiverem em uso
Ativadas apenas quando necessrio para o fornecedor e
desativadas quando no estiverem em uso.
Permitir que fornecedores tenham acesso integral
sua rede caso eles precisem dar suporte ao seu
sistema aumenta as chances de acesso no
autorizado, seja de um usurio no ambiente do
fornecedor ou de um indivduo mal-intencionado
que descubra e use esse ponto de entrada externo
sempre pronto para sua rede. Ativar o acesso
apenas pelos perodos de tempo necessrios e
desativar assim que no for mais necessrio, ajuda
a prevenir o mau uso destas conexes.
O monitoramento do acesso do fornecedor
proporciona a garantia de que os fornecedores
estejam acessando apenas os sistemas
necessrios e somente durante os perodos de
tempo aprovados.
8.1.5.b Questione os funcionrios e observe os processos
para verificar se as contas de acesso remoto do fornecedor
so monitoradas quando esto em uso.
8.1.6 Limite tentativas de acesso
repetidas bloqueando o ID do usurio
aps seis tentativas, no mximo.
8.1.6.a Para obter uma amostra dos componentes do sistema,
inspecione as configuraes do sistema para verificar se os
parmetros de autenticao esto definidos para exigir que as
contas de usurios sejam bloqueadas aps seis tentativas
invlidas de efetuar logon.
Sem a implementao de mecanismos de bloqueio
de conta, um invasor pode tentar continuamente
adivinhar uma senha por meio de ferramentas
manuais ou automatizadas (por exemplo, cracking
de senha) at ter sucesso e ganhar acesso conta

8.1.6.b Procedimento de teste adicional para prestadores
de servios: Analise os processos internos e a documentao
do cliente/usurio e observe os processos implementados
para verificar se as contas do usurio que no cliente so
bloqueadas temporariamente aps seis tentativas invlidas de
acesso.
do usurio.
8.1.7Defina a durao do bloqueio
para um mnimo de 30 minutos ou at
que o administrador ative o ID do
usurio.
analise as configuraes do sistema para verificar se os
parmetros de senha esto definidos para exigir que assim
que a conta de um usurio for bloqueada, ela permanecer
dessa forma por pelo menos 30 minutos ou at que um
administrador do sistema reconfigure a conta.
Se uma conta estiver bloqueada em funo de uma
pessoa tentar continuamente adivinhar a senha, os
controles para atrasar a reativao dessas contas
bloqueadas evitaro que o indivduo mal-
intencionado continue a tentar adivinhar a senha
(ele ter de parar por pelo menos 30 minutos at a
conta ser reativada). Alm disso, se a reativao
precisar ser solicitada, a administrao ou o servio
de suporte pode validar se o real proprietrio da
conta que est solicitando a reativao.
8.1.8 Se uma sesso estiver ociosa
por mais de 15 minutos, solicite que o
usurio redigite a senha para reativar o
terminal.
analise as definies de configurao do sistema para verificar
se os recursos de tempo esgotado de ociosidade do
sistema/sesso foram definidos para 15 minutos ou menos.
Quando os usurios se distanciam de uma mquina
aberta com acesso a componentes crticos do
sistema e dados do portador do carto, essa
mquina poder ser usada por outras pessoas na
ausncia do usurio, resultando em acesso no
autorizado conta e/ou mau uso dela.
A reautenticao pode ser aplicada no nvel de
sistema para proteger todas as sesses em
funcionamento naquela mquina, ou no nvel de
aplicativo.

8.2Alm de atribuir uma ID exclusiva,
garanta que um controle adequado da
autenticao do usurio para usurios
que no sejam clientes e
administradores em todos os
componentes do sistema, empregando
pelo menos um dos mtodos a seguir
para autenticar todos os usurios:
Algo que voc sabe, como uma
senha ou frase de senha
Algo que voc tem, como um
dispositivo de token ou um smart
card
Algo que voc , como a biomtrica.
8.2Para verificar se os usurios so autenticados usando o ID
exclusivo e a autenticao adicional (por exemplo, uma
senha/frase) para acessar o ambiente de dados do portador do
carto, desempenhe o seguinte:
Analise a documentao que descreve o(s) mtodo(s) de
autenticao usado(s).
Para cada tipo do mtodo de autenticao usado e para
cada tipo do componente de sistema, observe uma
autenticao para verificar se a autenticao est sendo
executada de acordo com o(s) mtodo(s) de autenticao
documentado(s).
Esses mtodos de autenticao, quando usados
alm dos IDs exclusivos, ajudam a proteger os IDs
dos usurios contra o comprometimento, visto que
quem estiver tentando as necessidades de
comprometimento precisa conhecer tanto o ID
exclusivo quanto a senha (ou outro item de
autenticao). Observe que um certificado digital
uma opo vlida para "algo que voc tem" desde
que seja exclusivo.
Como uma das primeiras etapas tomadas por um
indivduo mal-intencionado para comprometer um
sistema explorar senhas fracas ou inexistentes,
importante implementar bons processos para
controle de autenticao.

8.2.1 Use criptografia forte, converta
todas as credenciais de autenticao
(como senhas/frases) ilegveis durante
a transmisso e armazenamento em
todos os componentes do sistema.
8.2.1.a Analise a documentao do fornecedor e os ajustes da
configurao do sistema para verificar se as senhas esto
protegidas com criptografia forte durante a transmisso e o
armazenamento.
Muitos dispositivos de rede e aplicativos transmitem
senhas sem criptografia e legveis por uma rede
e/ou armazenam as senhas sem criptografia. Um
indivduo mal-intencionado pode facilmente
interceptar as senhas sem criptografia durante a
transmisso usando um sniffer, ou ento acessar
diretamente as senhas no criptografas em arquivos
onde eles so armazenados e usar esses dados
para obter acesso no autorizado.
8.2.1.bPara obter uma amostra dos componentes do sistema,
analise os arquivos de senha para verificar se as senhas esto
ilegveis durante o armazenamento.
8.2.1.cPara obter uma amostra dos componentes do sistema,
analise as transmisses de dados para verificar se as senhas
esto ilegveis durante a transmisso.
8.2.1.d Procedimento de teste adicional para prestadores
de servios: Observe os arquivos de senha para verificar se
as senhas do cliente esto ilegveis durante o
armazenamento.
8.2.1.e Procedimento de teste adicional para prestadores
de servios: Observe as transmisses de dados para verificar
se as senhas do cliente esto ilegveis durante a transmisso.
8.2.2 Verifique a identidade do usurio
antes de modificar qualquer credencial
de autenticao, por exemplo,
executar restaurao da senha,
provisionar novos tokens ou gerar
novas chaves.
8.2.2Analise os procedimentos de autenticao para modificar
as credenciais de autenticao e observe a equipe de
segurana para verificar se, caso um usurio solicite uma
redefinio credencial de autenticao por telefone, e-mail,
Web ou outro mtodo remoto, a identidade do usurio
comprovada antes que a credencial de autenticao seja
modificada.
Muitos indivduos mal-intencionados usam a
engenharia social(por exemplo, ligam para o
servio de suporte e agem como um usurio
legtimo) para trocar a senha, de forma que possam
utilizar um ID de usurio. Considere usar uma
pergunta secretaque s o prprio usurio possa
responder para ajudar os administradores a
identificar o usurio antes de redefinir ou modificar
as credencias de autenticao.

8.2.3 As senhas/frases devem atender
ao seguinte:
Exigir uma extenso mnima de
pelo menos sete caracteres.
Conter caracteres numricos e
alfabticos.
Alternativamente, as senhas/frases
devem ter complexidade e fora pelo
menos equivalentes aos parmetros
especificados acima.
8.2.3a Para obter uma amostra dos componentes do sistema,
se os parmetros de senha do usurio esto definidos para
solicitar pelo menos a seguinte complexidade/fora:
Exigir uma extenso mnima de pelo menos sete
caracteres.
Conter caracteres numricos e alfabticos.
Senhas/frases fortes so a primeira linha de defesa
para uma rede, pois um indivduo mal-intencionado
muitas vezes tentar primeiro encontrar contas com
senhas fracas ou inexistentes. Se as senhas forem
curtas ou fceis de adivinhar, relativamente fcil
para um indivduo mal-intencionado localizar essas
contas fracas e comprometer uma rede parecendo
um ID de usurio vlido.
Este requisito especifica se os sete caracteres
numricos e alfabticos devem ser usados para
senhas/frases. Para os casos em que este mnimo
no possvel devido a limitaes tcnicas, as
entidades podem usar "fora equivalente" para
avaliar sua alternativa. O NIST SP 800-63-1 define
"entropia" como "uma medida de dificuldade de
adivinhar ou determinar uma senha ou chave". Este
documento e outros que abordam a "entropia de
senha" podem ser consultados para obter mais
informaes em valor de entropia aplicvel e para o
entendimento da variao da fora equivalente da
senha para senhas/frases de diferentes formatos.
do cliente/usurio para verificar se as senhas do usurio que
no cliente so exigidas para atender pelo menos a seguinte
complexidade/fora:
Exigir uma extenso mnima de pelo menos sete
caracteres.
Conter caracteres numricos e alfabticos.
8.2.4 Altere as senhas/frases do
usurio pelo menos a cada 90 dias.
se os parmetros de senha do usurio esto definidos para
solicitar que os usurios alterem as senhas pelo menos a cada
90 dias.
As senhas que esto vlidas por muito tempo sem
modificao proporcionam mais tempo a indivduos
mal-intencionados para tentar burlar a senha/frase.
de servios: Revise os processos internos e a documentao
do cliente/usurio para verificar se:
As senhas dos usurios que no so clientes devem ser
alteradas periodicamente; e
Usurios que no so clientes recebem instrues sobre
quando e sob quais circunstncias as senhas devem ser
alteradas.

8.2.5 No permita que ningum envie
uma nova senha que seja a mesma de
uma das quatro ltimas senhas que
tenha sido usada.
obtenha e analise as definies da configurao do sistema
para verificar se os parmetros de senha esto definidos para
solicitar que as novas senhas no possam ser iguais s quatro
senhas usadas anteriormente.
Se o histrico da senha no for mantido, a
efetividade da alterao da senha reduzida, j que
as senhas anteriores podem ser reutilizadas vrias
vezes. Determinar que as senhas no sejam
reutilizadas por um perodo de tempo reduz a
probabilidade de que senhas que foram adivinhadas
ou violadas sejam usadas futuramente.

do cliente/usurio para verificar se as novas senhas do usurio
que no cliente no podero ser iguais s quatro senhas
anteriores.
8.2.6 Defina as senhas/frases para o
primeiro uso e ao reiniciar com um
valor exclusivo para cada usurio e
altere imediatamente aps a primeira
utilizao.
8.2.6 Analise os procedimentos de senha e observe a equipe
de segurana para verificar se as senhas iniciais para usurios
novos e senhas de reinicializao para usurios existentes so
definidas com um valor exclusivo para cada usurio e
alteradas aps a primeira utilizao.
Se a mesma senha for usada para cada novo
usurio, um usurio interno, ex-funcionrio ou
indivduo mal-intencionado poder conhecer ou
descobrir facilmente essa senha e us-la para obter
acesso s contas.
8.3 Incorpore autenticao de dois
fatores para o acesso de rede remota
originado fora da rede por funcionrios
(incluindo usurios e administradores) e
todos os terceiros (incluindo acesso do
fornecedor para suporte ou
manuteno).
Observao: A autenticao de dois
fatores exige que dois dos trs mtodos
de autenticao (consulte o Requisito
8.2 para obter descries dos mtodos
de autenticao) sejam usados para
autenticao. Usar um fator duas vezes
(por exemplo, usar duas senhas
separadas) no caracteriza autenticao
de dois fatores.
Exemplos de tecnologias de dois fatores
incluem autenticao remota e servio
de dial-in (RADIUS) com tokens; sistema
de controle de acesso ao controlador de
acesso ao terminal (TACACS) com
tokens; e outras tecnologias que
8.3.a Analise as configuraes do sistema para os sistemas e
servidores de acesso remoto para verificar se a autenticao de
dois fatores exigida para:
Todos os acessos remotos dos funcionrios
Todos os acessos remotos de fornecedores/terceiros
(incluindo acesso aos componentes do sistema e aplicativos
para suporte ou manuteno).
A autenticao de dois fatores exige duas formas de
autenticao para acessos com maior risco, como
aqueles originados de fora de rede
Esse requisito se aplica a toda a equipe, incluindo
usurios gerais, administradores e fornecedores
(para suporte ou manuteno), com acesso remoto
rede, onde esse acesso remoto possa levar ao
acesso do ambiente de dados do portador do
carto.
Se o acesso remoto for para a rede de uma
entidade que possui segmentao adequada, como
a impossibilidade de acesso por parte dos usurios
remotos ou de impacto ao ambiente de dados do
portador do carto, a autenticao de dois fatores
para o acesso remoto quela rede no ser exigida.
No entanto, a autenticao de dois fatores exigida
para qualquer acesso remoto a redes com acesso
ao ambiente de dados do portador do carto e
recomendvel para todo o acesso remoto a redes
de entidades.
8.3 Observe um exemplo da equipe (por exemplo, usurios e
administradores) conectando-se remotamente rede e verifique
se pelo menos dois dos trs mtodos de autenticao so
usados.

facilitam a autenticao de dois fatores.
8.4 Registre e comunique os
procedimentos e polticas de
autenticao a todos os usurios,
incluindo:
Orientao sobre selecionar
credenciais fortes de autenticao
Orientao sobre como os usurios
devem proteger suas credenciais de
autenticao
Instrues para no reutilizar senhas
anteriormente usadas
Instrues para alterar a senha se
houver suspeita de que ela possa
estar comprometida.
8.4.a Analise os procedimentos e questione os funcionrios para
verificar se os procedimentos e polticas de autenticao so
distribudos para todos os usurios.
Comunicar os procedimentos de
autenticao/senha para todos os usurios ajuda-os
a compreender e cumprir com as polticas.
Por exemplo, a orientao sobre selecionar senhas
fortes pode incluir sugestes para ajudar a equipe a
selecionar senhas difceis de adivinhar que no
contenham palavras do dicionrio e informaes
sobre o usurio (como ID do usurio, nomes de
familiares, data de aniversrio, etc.). A orientao
para proteger as credenciais de autenticao pode
incluir no anotar senhas ou salv-las em arquivos
no seguros e estar alerta a indivduos mal-
intencionados que possam tentar explorar suas
senhas (por exemplo, ligando para um funcionrio e
perguntando sua senha para que ele possa
resolver um problema).
Instruir os usurios a alterar suas senhas se houver
a possibilidade de ela no ser mais segura pode
evitar que usurios mal-intencionados usem uma
senha legtima para obter acesso no autorizado.
8.4.b Analise os procedimentos e polticas de autenticao que
so distribudos aos usurios e verifique se eles incluem:
Orientao sobre selecionar credenciais fortes de
autenticao
Orientao sobre como os usurios devem proteger suas
credenciais de autenticao.
Instrues para os usurios no reutilizarem senhas
anteriormente usadas
Instrues para alterar a senha se houver suspeita de que
ela possa estar comprometida.
8.4.c Questione alguns usurios para verificar se eles esto
familiarizados com os procedimentos e polticas de
autenticao.
8.5 No use IDs de grupos,
compartilhados ou genricos, senhas ou
outros mtodos de autenticao
conforme segue:
IDs genricos de usurios so
desativados ou removidos.
IDs de usurios compartilhados no
existem para a administrao do
sistema e outras funes crticas.
IDs de usurios compartilhados e
genricos no so usados para
administrar quaisquer componentes
do sistema.
8.5.aPara obter uma amostra dos componentes do sistema,
analise as listas de ID do usurio para verificar o seguinte:
IDs genricos de usurios so desativados ou removidos.
IDs de usurios compartilhados para atividades de
administrao do sistema e outras funes crticas no
existem.
IDs de usurios compartilhados e genricos no so usados
para administrar quaisquer componentes do sistema.
Se vrios usurios compartilharem as mesmas
credenciais de autenticao (conta e senha, por
exemplo), torna-se impossvel controlar o acesso ao
sistema e atividades de um indivduo. Isso evita que
uma entidade assuma a responsabilidade de, ou
faa um registro eficaz das aes de um indivduo,
pois uma determinada ao pode ter sido executada
por qualquer pessoa no grupo que saiba as
credencias de autenticao.
8.5.b Analise as polticas/procedimentos de autenticao para
verificar se o uso de senhas e/ou IDs compartilhados e de grupo
ou outros mtodos de autenticao so explicitamente proibidos.
8.5.c Questione os administradores do sistema para verificar se
as senhas e/ou IDs de grupo ou compartilhados ou outros
mtodos de autenticao no so distribudos, mesmo se forem
solicitados.

8.5.1 Requisito adicional para
prestadores de servios: Os
prestadores de servio com acesso
remoto ao local do cliente (por
exemplo, para suporte de servidores
ou sistemas POS) devem usar uma
credencial de autenticao exclusiva
(como uma senha/frase) para cada
cliente.
Observao: Este requisito no tem o
objetivo de se aplicar a provedores de
hospedagem compartilhada que
acessam seu prprio ambiente de
hospedagem, onde vrios ambientes do
cliente so hospedados.
Observao: O requisito 8.5.1
considerado uma das melhores prticas
at 30 de junho de 2015 quando passar
a ser um requisito.
8.5.1 Procedimento de teste adicional para prestadores de
servios: Analise as polticas e procedimentos de
autenticao e questione os funcionrios para verificar se so
usadas autenticaes diferentes para acesso a cada cliente.
Para prevenir o comprometimento de vrios clientes
devido ao uso de um conjunto nico de credenciais,
os fornecedores com contas de acesso remoto aos
ambientes do cliente devem usar uma credencial de
autenticao diferente para cada cliente.
Tecnologias, como mecanismos de dois fatores,
que oferecem uma credencial nica para cada
conexo (por exemplo, por meio de uma senha de
uso comum) tambm podem atender ao objetivo
deste requisito.
8.6 Onde forem usados outros
mecanismos de autenticao (por
exemplo, tokens de segurana fsicos ou
virtuais, smart cards, certificados, etc.), o
uso destes mecanismos deve ser
atribudo conforme segue:
Os mecanismos de autenticao
devem ser atribudos a uma conta
individual e no compartilhados entre
vrias contas.
Controles fsicos e/ou virtuais devem
ser implementados para garantir que
apenas a conta pretendida possa
usar o mecanismo para obter
acesso.
8.6.a Analise as polticas e procedimentos de autenticao para
verificar se os procedimentos para usar os mecanismos de
autenticao, como tokens de segurana fsicos, smart cards e
certificados esto definidos e incluem:
Os mecanismos de autenticao so atribudos a uma conta
individual e no compartilhados entre vrias contas.
Controles fsicos e/ou virtuais esto definidos para garantir
que apenas a conta pretendida possa usar o mecanismo
para obter acesso.
Se os mecanismos de autenticao do usurio,
como tokens, smart cards e certificados puderem
ser usados por vrias contas, pode ser impossvel
identificar o indivduo que utiliza o mecanismo de
autenticao. Ter controles fsicos e/ou virtuais (por
exemplo, um PIN, dados biomtricos ou uma senha)
para identificar exclusivamente o usurio da conta
evitar que usurios no autorizados obtenham
acesso atravs do uso de um mecanismo de
autenticao compartilhado.

8.6.b Questione a equipe de segurana para verificar se os
mecanismos de autenticao so atribudos a uma conta e no
compartilhados entre vrias contas.
8.6.c Analise os ajustes da cofigurao do sistema e/ou os
controles fsicos, conforme aplicvel, para verificar se os
controles esto implementados para garantir que apenas a
conta pretendida possa usar o mecanismo para obter acesso.
8.7 Todos os acessos para qualquer
banco de dados que contenha dados do
portador do carto (incluindo acesso por
meio de aplicativos, administradores e
todos os outros usurios) so restritos
conforme segue:
Todos os acessos, consultas e aes
do usurio no banco de dados
ocorrem atravs de mtodos
programticos.
Apenas os administradores do banco
de dados podem acessar
diretamente ou consultar o banco de
dados.
Os IDs dos aplicativos para os
aplicativos do banco de dados s
podem ser usados pelos aplicativos
(e no por usurios individuais ou
outros processos sem aplicativo).
8.7.a Analise as definies de configurao do aplicativo e do
banco de dados para verificar se todos os usurios so
autenticados antes do acesso.
Sem autenticao do usurio para acesso a bancos
de dados e aplicativos, o potencial para acesso no
autorizado ou mal-intencionado aumenta e esse
acesso no pode ser registrado, pois o usurio no
foi autenticado e, assim, no conhecido pelo
sistema. Alm disso, o acesso ao banco de dados
s deve ser concedido por meio de mtodos
programticos (por exemplo, por meio de
procedimentos armazenados) e no por acesso
direto ao banco de dados por usurios finais (exceto
para DBAs, que podem precisar de acesso direto ao
banco de dados para as tarefas administrativas).
8.7.b Analise as definies de configurao do aplicativo e do
banco de dados para verificar se todos os acessos, consultas e
aes dos usurios (por exemplo, mover, copiar, excluir) nos
bancos de dados so por meio apenas de mtodos
programticos (por exemplo, atravs dos procedimentos
armazenados).
8.7.c Analise as configuraes do controle de acesso do banco
de dados e as definies de configurao do aplicativo e do
banco de dados para verificar se o acesso direto ou consultas
ao banco de dados so restritos aos administradores.
8.7.d Analise as configuraes do controle de acesso do banco
de dados, as definies de configurao do aplicativo do banco
de dados e os IDs dos aplicativos relacionados para verificar se
os IDs dos aplicativos podem ser usados somente pelos
aplicativos (e no apenas por usurios individuais ou outros
processos).
para identificao e autenticao
estejam documentados, em uso e
conhecidos por todas as partes
envolvidas.
operacionais para identificao e autenticao esto:
Documentados,
Em uso, e
operacionais para controlar continuamente as
identificaes e autorizaes.

Requisito 9: Restrinja o acesso fsico aos dados do portador do carto
Qualquer acesso fsico aos dados ou sistemas que armazenam dados do portador do carto fornecem a oportunidade para as pessoas
acessarem dispositivos ou dados e removerem sistemas ou cpias impressas e deve ser restrito de forma adequada. Para as finalidades do
Requisito 9, "funcionrio" refere-se a funcionrios que trabalham em perodo integral e meio-perodo, funcionrios e equipes temporrias e
prestadores de servios e consultores que atuem com presena fsica no endereo da entidade. Um visitante refere-se a um fornecedor,
convidado de um funcionrio, equipes de servio ou qualquer pessoa que precise adentrar as dependncias por um breve perodo, normalmente
um dia, no mximo. "Mdia" refere-se a todas as mdias em papel ou eletrnicas que contm dados do portador do carto.
REQUISITOS DO PCI DSS PROCEDIMENTOS DE TESTE
ORIENTAO
9.1Use controles de entrada facilitados e
adequados para limitar e monitorar o
acesso fsico aos sistemas no ambiente
de dados do portador do carto.
9.1Verifique a existncia dos controles de segurana fsica em
cada ambiente com computador, central de dados e outras reas
fsicas com sistemas no ambiente de dados do portador do
carto.
Verifique se o acesso controlado com leitores de
credenciais ou outros dispositivos, incluindo credenciais
autorizadas e bloqueio e chave.
Observe a tentativa de um administrador do sistema de
efetuar logon em consoles visando aos sistemas selecionados
aleatoriamente no ambiente do portador do carto e verifique
se eles esto "bloqueados" para impedir o uso no
autorizado.
Sem controles fsicos de acesso, como sistemas
de crachs e controles de porta, usurios no
autorizados podem facilmente obter acesso s
instalaes para roubar, desativar, interromper ou
destruir sistemas crticos e dados do portador do
carto.
Bloquear telas de logon em consoles evita que
pessoas no autorizadas obtenham acesso a
informaes confidenciais, alterando as
configuraes do sistema, introduzindo
vulnerabilidades na rede ou destruindo registros.
9.1.1 Use cmeras de vdeo ou outros
mecanismos de controle de acesso
para monitorar o acesso fsico
9.1.1.a Verifique se cmeras de vdeo e/ou outros mecanismos
de controle de acesso foram implantados para monitorar os
pontos de entrada/sada das reas confidenciais.
Ao investigar violaes fsicas, esses controles
podem ajudar a identificar indivduos que
acessaram fisicamente as reas confidenciais,

ORIENTAO
individual a reas confidenciais.
Analise os dados coletados e relacione
com outras entradas. Armazene, por
pelo menos trs meses, a menos que
seja restringido de outra forma pela lei.
Observao: "reas confidenciais"
referem-se a qualquer central de dados,
sala de servidores ou qualquer rea que
contenha sistemas que armazenem,
processem ou transmitam dados do
portador do carto. Isso exclui reas
voltadas ao pblico nas quais h
somente terminais do ponto de venda
presentes, como as reas dos caixas em
uma loja de varejo.
9.1.1.b Verifique se cmeras de vdeo ou outros mecanismos
de controle de acesso esto protegidos contra adulterao ou
desativao.
bem como quando eles entraram e saram.
Criminosos que tentam obter acesso fsico s
reas confidenciais muitas vezes tentaro
desativar ou desviar os controles de
monitoramento. Para proteger estes controles
contra adulteraes, cmeras de vdeo podem ser
posicionadas de forma que fiquem fora de alcance
e/ou sejam monitoradas para detectar
falsificaes. Da mesma forma, os mecanismos de
controle de acesso podem ser monitorados ou ter
protees fsicas instaladas para evitar que sejam
danificados ou desativados por indivduos mal-
intencionados.

9.1.1.c Verifique se cmeras de vdeo ou outros mecanismos
de controle de acesso so monitorados e se os dados das
cmeras ou outros mecanismos so armazenados por pelo
menos trs meses.
Exemplos de reas confidenciais incluem salas de
servidor do banco de dados corporativo, salas de
escritrios administrativos em um local de revenda
que armazene dados do portador do carto e
reas de armazenamento de grandes quantidades
de dados do portador do carto. As reas
confidenciais devem ser identificadas por cada
organizao para garantir que os controles de
monitoramento fsicos adequados sejam
implementados.

ORIENTAO
9.1.2 Implemente controles fsicos e/ou
virtuais para restringir o acesso a
pontos de rede acessveis
publicamente.
Por exemplo, pontos de rede localizados
em reas pblicas e reas acessveis a
visitantes podem ser desativados e
somente ativados quando o acesso
rede explicitamente autorizado.
Alternativamente, processos podem ser
implementados para garantir que os
visitantes sempre sejam acompanhados
nas reas com pontos de rede ativos.
9.1.2 Questione os funcionrios responsveis e observe os
locais de pontos de rede publicamente acessveis para verificar
se controles fsicos e/ou virtuais esto implementados para
restringir o acesso a estes pontos de rede.
Restringir o acesso aos pontos de rede (ou portas
de rede) evita que indivduos mal-intencionados se
conectem em pontos de rede prontamente
disponveis e obtenham acesso aos recursos de
rede internos.
Se forem usados controles fsicos ou virtuais, ou
os dois, eles devem ser suficientes para evitar que
um indivduo ou dispositivo no autorizado consiga
se conectar rede.
9.1.3 Restrinja o acesso fsico a pontos
sem fio de acesso, gateways,
dispositivos portteis, hardwares de
comunicao/rede e linhas de
telecomunicao.
9.1.3 Verifique se o acesso fsico a pontos sem fio de acesso,
gateways, dispositivos portteis, hardwares de
comunicao/rede e linhas de telecomunicao restrito
adequadamente.
Sem segurana no acesso a componentes e
dispositivos sem fio, indivduos mal-intencionados
podem usar os dispositivos sem fio da sua
empresa que no estejam sendo utilizados para
acessar os recursos de rede ou at para conectar
seus prprios dispositivos rede sem fio para
obter acesso no autorizado. Alm disso, fazer a
segurana dos materiais de comunicao e rede
evita que usurios mal-intencionados interceptem
o trfego da rede ou conectem fisicamente seus
prprios dispositivos aos recursos de rede com fio.
9.2 Desenvolva procedimentos para
diferenciar facilmente a equipe interna
dos visitantes e inclua:
Identificar novos funcionrios ou
visitantes (por exemplo, conceder
crachs)
Modificaes nos requisitos de
acesso
Anular ou excluir identificaes de
funcionrios que se desligaram da
9.2 Analise os processos documentados para verificar se esto
definidos procedimentos para identificar e diferenciar os
funcionrios dos visitantes.
Verifique se os processos incluem o seguinte:
Identificar novos funcionrios ou visitantes (por exemplo,
conceder crachs),
Modificar os requisitos de acesso e
Anular identificaes de funcionrios que se desligaram da
empresa e de visitantes que encerraram sua atividade (como
crachs de identificao)
Identificar visitantes autorizados para que sejam
facilmente distinguidos dos funcionrios do local
evita que os visitantes no autorizados acessem
reas contendo dados do portador do carto.

ORIENTAO
empresa e de visitantes que
encerraram sua atividade (como
crachs de identificao).
9.2.b Observe os processos para identificar e diferenciar os
funcionrios dos visitantes para verificar se:
Os visitantes so claramente identificados, e
fcil diferenciar os visitantes dos membros da equipe
interna.
9.2.c Verifique se o acesso ao processo de identificao (como
um sistema de crachs) limitado a funcionrios autorizados.
9.2.d Analise os mtodos de identificao (como crachs de
identificao) em uso para verificar se identificam claramente os
visitantes e se fcil distinguir funcionrios de visitantes.
9.3 Controle o acesso fsico dos
funcionrios s reas confidenciais
conforme segue:
O acesso deve ser autorizado e com
base na funo do indivduo.
O acesso anulado imediatamente
ao trmino da atividade e todos os
mecanismos de acesso fsico, como
chaves, cartes de acesso, etc., so
devolvidos e desativados.
9.3.a Para obter uma amostra de funcionrios com acesso fsico
ao CDE, questione o funcionrio responsvel e observe as listas
de controle de acesso para verificar se:
O acesso ao CDE est autorizado.
O acesso necessrio para a funo da pessoa.
Controlar o acesso fsico ao CDE ajuda a garantir
que apenas funcionrios autorizados com
necessidade comercial legtima tero acesso.
Quando um funcionrio deixa a empresa, todos os
mecanismos de acesso fsico devem ser
devolvidos e desativados imediatamente (assim
que possvel) aps a sua sada, para garantir que
ele no tenha acesso fsico ao CDE quando no
for mais funcionrio da empresa.
9.3.b Observe o acesso dos funcionrios ao CDE para verificar
se todos so autorizados antes de receberem o acesso.
9.3.c Selecione exemplos de funcionrios desligados e revise as
listas de controle de acesso para verificar se os mesmos no tm
acesso fsico ao CDE.

ORIENTAO
9.4 Implemente procedimentos para
identificar e autorizar visitantes.
Os procedimentos devem incluir o
seguinte:
9.4 Verifique se os controles de acesso e autorizao dos
visitantes esto implementados da seguinte forma:
O controle de visitantes importante para reduzir a
possibilidade de pessoas no autorizadas e mal-
intencionadas obterem acesso s instalaes (e
possivelmente aos dados do portador do carto).
Os controles de visitantes garantem que eles
sejam identificados como visitantes, de forma que
os funcionrios possam monitorar suas atividades
e que o acesso esteja restrito somente durao
de sua visita.
Garantir que os crachs de visitantes sejam
devolvidos ao final de sua visita evita que pessoas
mal-intencionadas utilizem uma passagem
anteriormente autorizada para obter acesso fsico
ao prdio aps o trmino de sua visita.
Um log de visitantes documentando as
informaes mnimas sobre eles de manuteno
fcil e barata e ajuda a identificar o acesso fsico a
um edifcio ou a uma sala e um possvel acesso
aos dados do portador do carto.
9.4.1 Os visitantes devem obter
autorizao antes de entrar e serem
sempre acompanhados em reas nas
quais os dados do portador do carto
so processados ou mantidos.
9.4.1.a Observe os procedimentos e questione os funcionrios
para verificar se os visitantes devem obter autorizao antes de
entrar e serem sempre acompanhados em reas nas quais os
dados do portador do carto so processados ou mantidos.
9.4.1.b Observe o uso dos crachs de visitante ou outra
identificao para verificar se um crach de token fsico no
permite acesso desacompanhado a reas fsicas onde os
dados do portador do carto so processados ou mantidos.
9.4.2 Os visitantes so identificados e
recebem um crach ou outra
identificao que expira e que
distingue visivelmente os visitantes dos
funcionrios internos.
9.4.2.a Observe as pessoas na instalao para verificar o uso
dos crachs de visitante ou outra identificao e se fcil
distinguir os visitantes dos funcionrios.
9.4.2.b Verifique se os crachs de visitante ou outra
identificao tm validade.
9.4.3 solicitado que os visitantes
apresentem o crach ou identificao
antes de sair das dependncias ou na
data do vencimento.
9.4.3 Observe os visitantes que saem das dependncias para
verificar se solicitado que eles apresentem seu crach ou
outra identificao na sada ou ao vencimento.
9.4.4 Um registro de visitantes usado
para manter uma trilha de auditoria da
atividade do visitante nas
dependncias, assim como aos
ambientes com computador e centrais
de dados onde os dados do portador
do carto so armazenados ou
transmitidos.
Documente no registro o nome do
9.4.4.a Verifique se um registro de visitantes est sendo usado
para registrar o acesso fsico s dependncias, assim como aos
ambientes com computador e centrais de dados onde os dados
do portador do carto so armazenados ou transmitidos.
9.4.4.b Verifique se o registro contm:
O nome do visitante,
A empresa representada, e
O funcionrio que autoriza o acesso fsico.

ORIENTAO
visitante, a empresa representada e o
funcionrio que autoriza o acesso
fsico.
Armazene esse registro por pelo
menos trs meses, a menos que seja
restringido de outra forma pela lei.
9.4.4.c Verifique se o registro mantido por pelo menos trs
meses.
9.5 Proteja toda a mdia fisicamente. 9.5 Verifique se os procedimentos para proteger os dados do
portador do carto incluem controles para proteger fisicamente
todas as mdias (incluindo, entre outros, a computadores, mdias
eletrnicas removveis, recebimentos de documentos impressos,
relatrios impressos e faxes).
Os controles para proteger fisicamente as mdias
tm o objetivo de evitar que pessoas no
autorizadas obtenham acesso aos dados do
portador do carto em qualquer tipo de mdia. Os
dados do portador do carto estaro suscetveis a
visualizao, cpia ou digitalizao no autorizada
caso estejam desprotegidos enquanto estiverem
em mdia porttil, forem impressos ou deixados na
mesa de algum.
9.5.1 Armazene backups de mdia em
um local seguro, preferencialmente em
outras instalaes, como um lugar
alternativo de backup ou uma
instalao comercial de
armazenamento. Analise a segurana
do local pelo menos uma vez por ano.
9.5.1.a Observe a segurana fsica do local de armazenamento
para confirmar que o armazenamento da mdia de backup est
seguro.
Se armazenados em um local no protegido, os
backups que contm dados do portador do carto
podem ser facilmente perdidos, roubados ou
copiados com ms intenes.
9.5.1.b Verifique se a segurana do local de armazenamento
revisada ao menos anualmente.
Revisar periodicamente o local de armazenamento
permite que a organizao resolva problemas de
segurana em tempo hbil, minimizando o
potencial de risco.
9.6 Mantenha controle rigoroso quanto
distribuio interna ou externa de
qualquer tipo de mdia, incluindo o
seguinte:
9.6 Verifique se h uma poltica para controlar a distribuio de
mdias que contm dados do portador do carto e se a poltica
abrange todas as mdias distribudas, incluindo as distribudas s
pessoas.
Procedimentos e processos ajudam a proteger os
dados do portador do carto em mdias
distribudas a usurios internos e/ou externos. Sem
tais procedimentos, os dados podero ser perdidos
ou roubados e usados para fins fraudulentos.

ORIENTAO
9.6.1 Classifique a mdia para que a
confidencialidade dos dados possa ser
determinada.
9.6.1 Verifique se toda a mdia foi classificada para que a
confidencialidade dos dados possa ser determinada.
importante que a mdia seja identificada para
que seu status de classificao possa ser
facilmente discernvel. A mdia no identificada
como confidencial pode no ser protegida
adequadamente ou ser roubada.
Observao: Isto no significa que as mdias
precisam ter anexado um rtulo "Confidencial"; o
objetivo que a organizao tenha identificado a
mdia que contm dados confidenciais para que
possa proteg-los.
9.6.2 Envie a mdia via mensageiro
seguro ou outro mtodo de entrega
que possa ser monitorado com
preciso.
9.6.2.a Questione os funcionrios e analise os registros para
verificar se toda a mdia enviada para fora das dependncias
registrada e encaminhada via mensageiro seguro ou outro
mtodo de entrega que possa ser monitorado.
A mdia pode ser perdida ou roubada se for
enviada por um mtodo no rastrevel, como
remessa postal. O uso de mensageiros seguros
para entregar mdias que contenham dados do
portador do carto permite que as organizaes
usem seus sistemas de rastreamento para manter
inventrio e localizao dos envios.
9.6.2.b Selecione um exemplo recente de vrios dias de
registros de monitoramento externo para todas as mdias e
verifique se os detalhes de rastreamento esto documentados.
9.6.3 Certifique-se de que o
gerenciamento aprova quaisquer e
todas as mdias que so movidas de
uma rea segura (incluindo quando as
mdias forem distribudas s pessoas).
9.6.3 Selecione um exemplo recente de vrios dias de logs de
monitoramento externo para todas as mdias. A partir da anlise
dos registros e questionamentos com os funcionrios
responsveis, verifique se obtida a autorizao adequada do
gerenciamento sempre que as mdias forem movidas de uma
rea segura (incluindo quando as mdias forem distribudas s
pessoas).
Sem um processo rigoroso para garantir que todos
os movimentos de mdia sejam aprovados antes
que ela seja removida das reas seguras, a mdia
no seria rastreada ou adequadamente protegida e
sua localizao seria desconhecida, levando a
mdias perdidas ou roubadas.
9.7 Mantenha um controle rigoroso sobre
o armazenamento e a acessibilidade das
mdias.
9.7 Obtenha e analise a poltica para controlar o armazenamento
e a manuteno dos documentos impressos e mdias eletrnicas
e verifique se a poltica requer inventrios de mdia peridicos.
Sem mtodos cuidadosos de inventrio e controles
de armazenamento, mdias roubadas ou ausentes
podem passar despercebidas por tempo indefinido.
Se a mdia no passar por inventrio, mdias
roubadas ou perdidas podem passar
despercebidas por bastante tempo.
9.7.1 Mantenha adequadamente os
registros do inventrio de todas as
mdias e realize inventrios das mdias
pelo menos uma vez por ano.
9.7.1 Revise o registro do inventrio das mdias para verificar
se os registros so mantidos e se os inventrios de mdia so
realizados pelo menos uma vez por ano.

ORIENTAO
9.8 Destrua as mdias quando no forem
mais necessrias por motivos legais ou
de negcios, conforme segue:
9.8 Analise a poltica de destruio peridica das mdias e
verifique se ela abrange todas as mdias e se define requisitos
para o seguinte:
Materiais impressos devem ser triturados, incinerados ou
amassados de forma que haja uma garantia razovel de que
esses materiais no possam ser recuperados.
Os containers de armazenamento usados para os materiais a
serem destrudos devem estar seguros.
Os dados do portador do carto nas mdias eletrnicas devem
ser indisponibilizados por meio de um programa de limpeza
segura (de acordo com os padres aceitos pelo setor quanto
excluso segura) ou destruindo fisicamente as mdias.
Se as etapas no forem seguidas par destruir as
informaes contidas em discos rgidos, drives
portteis, CD/DVDs ou papis antes do descarte,
indivduos mal-intencionados poder estar aptos a
recuperar as informaes da mdia descartada,
levando ao comprometimento dos dados. Por
exemplo, indivduos mal-intencionados podem usar
uma tcnica conhecida como dumpster diving, na
qual eles pesquisam em lixeiras e usam as
informaes encontradas para iniciar um invaso.
Proteger os containers de armazenamento usados
para os materiais que sero destrudos evita que
informaes confidenciais sejam capturadas
enquanto os materiais esto sendo coletados. Por
exemplo, containers "a serem triturados" podem ter
um bloqueio que evita o acesso a seu contedo ou
que previna fisicamente o acesso para dentro do
continer.
Exemplos de mtodos para destruir mdias
eletrnicas incluem limpeza segura,
desmagnetizao ou destruio fsica (como
esmagar ou triturar os discos rgidos).
9.8.1 Triture, incinere ou amasse
materiais impressos para que os dados
do portador do carto no possam ser
recuperados. Containers de
armazenamento usados para os
materiais a serem destrudos.
9.8.1.a Questione os funcionrios e analise os procedimentos
para verificar se os materiais impressos so picotados,
triturados, incinerados ou amassados para que haja garantia
razovel de que no possam ser reconstitudos.
9.8.1.b Analise os contineres de armazenamento usados para
os materiais que contm informaes a serem destrudas para
verificar se so seguros.
9.8.2 Torne os dados do portador do
carto nas mdias eletrnicas
irrecuperveis para que esses dados
no possam ser reconstitudos.
9.8.2 Verifique se os dados do portador do carto nas mdias
eletrnicas so tornados irrecuperveis por meio de um
programa de limpeza segura (de acordo com os padres
aceitos pelo setor quanto excluso segura, ou de outra forma,
destruindo fisicamente as mdias).

ORIENTAO
9.9Proteja contra falsificao e
substituio os dispositivos que
capturam os dados do carto de
pagamento por meio de interao fsica
direta com o carto.
Observao: Estes requisitos se
aplicam aos dispositivos de leitura do
carto usados em transaes com a
presena do carto (ou seja, de passar
ou inserir) no ponto de venda. Este
requisito no tem o objetivo de se aplicar
aos componentes de entrada de chave
manual, como teclados de computador e
teclados POS.
Observao: O requisito 9.9
considerado uma das melhores prticas
at 30 de junho de 2015 quando passar
a ser um requisito.
9.9 Analise as polticas e procedimentos para verificar se eles
incluem:
Manter uma lista de dispositivos
Inspecionar periodicamente os dispositivos para identificar
falsificaes ou substituies
Treinar os funcionrios para que reconheam
comportamentos suspeitos e para reportar a falsificao ou
substituio de dispositivos.
Criminosos tentam roubar os dados do portador do
carto roubando e/ou manipulando os terminais e
dispositivos de leitura do carto. Por exemplo, eles
tentaro roubar os dispositivos para que eles
possam saber como arromb-los e eles
geralmente tentam validar os dispositivos com
dispositivos fraudulentos que enviam a eles as
informaes do carto de pagamento sempre que
o carto inserido. Os criminosos tambm
tentaro adicionar componentes de "espionagem"
na parte externa dos dispositivos, que so
designados para capturar os detalhes do carto
antes mesmo de ser inserido, por exemplo,
anexando um leitor de carto adicional em cima do
leitor do carto original para que os detalhes do
carto sejam capturados duas vezes: uma vez pelo
componente do criminoso e depois pelo
componente legtimo do dispositivo. Dessa forma,
as transaes ainda podem ser concludas sem
interrupo enquanto o criminoso est "espiando"
as informaes do carto durante o processo.
Este requisito recomendado, mas no exigido,
para componentes de entrada de chave manual,
como teclados de computador e teclados POS.
Melhores prticas adicionais sobre a preveno de
espionagem esto disponveis no site do PCI SSC.
9.9.1 Mantenha uma lista atualizada de
dispositivos. A lista deve incluir o
seguinte:
Marca, modelo do dispositivo
Localizao do dispositivo (por
exemplo, o endereo do local ou
instalao onde o dispositivo est
localizado)
Nmero de srie do dispositivo ou
9.9.1.a Analise a lista de dispositivos para verificar se ela inclui:
Marca, modelo do dispositivo
Localizao do dispositivo (por exemplo, o endereo do
local ou instalao onde o dispositivo est localizado)
Nmero de srie do dispositivo ou outro mtodo de
identificao exclusivo.
Manter uma lista atualizada de dispositivos ajuda
uma organizao a controlar onde os dispositivos
devem estar e rapidamente identificar se um deles
est faltando ou perdido.
O mtodo para manter uma lista de dispositivos
pode ser automatizado (por exemplo, um sistema
de gerenciamento de dispositivos) ou manual (por
exemplo, documentado em registros de papel ou
eletrnicos). Para os dispositivos em trnsito, a
localizao pode incluir o nome do funcionrio para
9.9.1.b Selecione uma amostra de dispositivos a partir da lista e
observe as localizaes do dispositivo para verificar se a lista
est exata e atualizada.

ORIENTAO
outro mtodo de identificao
exclusivo.
9.9.1.c Questione os funcionrios para verificar se a lista de
dispositivos atualizada quando dispositivos so adicionados,
realocados, retirados, etc.
quem o dispositivo concedido.
9.9.2Inspecione periodicamente as
superfcies dos dispositivos para
detectar adulterao (por exemplo,
adio de espies aos dispositivos), ou
substituio (por exemplo, verificando
o nmero de srie ou outras
caractersticas do dispositivo para
verificar se ele no foi trocado por um
dispositivo fraudulento).
Observao: Exemplos de sinais de que
um dispositivo possa ter sido adulterado
ou substitudo incluem anexos
inesperados ou cabos conectados ao
dispositivo, rtulos de segurana
alterados ou ausentes, revestimento
quebrado ou de cor diferente, ou
alteraes no nmero de srie ou outras
marcas externas.
9.9.2.a Analise os procedimentos documentados para verificar
se os processos esto definidos para incluir o que segue:
Procedimentos para inspecionar os dispositivos
Frequncia de inspees.
As inspees regulares dos dispositivos ajudaro
as organizaes a detectar mais rapidamente
adulteraes ou substituies de um dispositivo e,
ento, minimizar o possvel impacto de usar
dispositivos fraudulentos.
O tipo de inspeo depender do dispositivo, por
exemplo, fotografias de dispositivos que so
conhecidos por serem seguros podem ser usadas
para comparar a aparncia atual de um dispositivo
com sua aparncia original para ver se ela mudou.
Outra opo pode ser usar uma caneta marcadora
segura, como um marcador de luz UV, para marcar
as superfcies e aberturas do dispositivo para que
qualquer adulterao ou substituio seja
aparente. Os criminosos frequentemente
substituiro a estrutura externa de um dispositivo
para ocultar sua adulterao e estes mtodos
podem ajudar a detectar tais atividades. Os
fornecedores dos dispositivos tambm podem
fornecer orientaes de segurana e guias "como
fazer" para ajudar a determinar se o dispositivo foi
adulterado.
A frequncia de inspees depender de fatores
como o local do dispositivo e se este frequentado
ou no. Por exemplo, dispositivos deixados em
reas pblicas sem superviso pelo funcionrio
pode ter inspees mais frequentes do que
dispositivos mantidos em reas seguras ou que
sejam supervisionados quando eles esto
acessveis ao pblico. O tipo e frequncia de
inspees so determinados pelo comerciante,
conforme definido pelo seu processo anual de
avaliao de riscos.
9.9.2.b Questione os funcionrios responsveis e observe os
processos de inspeo para verificar se:
Os funcionrios conhecem os procedimentos de inspeo
dos dispositivos.
Todos os dispositivos so inspecionados periodicamente
para evidncia de adulterao e substituio.

ORIENTAO
9.9.3 Treine os funcionrios para que
estejam cientes das tentativas de
adulterao ou substituio de
dispositivos. O treinamento deve incluir
o seguinte:
Verifique a identidade de qualquer
terceiro que alegue ser da equipe
de manuteno ou reparo, antes
de conceder acesso para
modificar ou resolver problemas
nos dispositivos.
No instale, substitua ou devolva
dispositivos sem verificao.
Esteja atento a comportamentos
suspeitos ao redor dos
dispositivos (por exemplo,
tentativas de desconectar ou abrir
os dispositivos por pessoas
desconhecidas).
Reporte comportamentos
suspeitos e indicaes de
adulterao ou substituio para a
equipe apropriada (por exemplo,
para um gerente ou funcionrio da
segurana).
9.9.3.a Analise os materiais de treinamento para os funcionrios
dos locais de ponto de venda para verificar se eles incluem o
treinamento do seguinte:
Verificar a identidade de qualquer terceiro que alegue ser
da equipe de manuteno ou reparo, antes de conceder
acesso para modificar ou resolver problemas nos
dispositivos
No instalar, substituir ou devolver dispositivos sem
verificao
Estar atento a comportamentos suspeitos ao redor dos
dispositivos (por exemplo, tentativas de desconectar ou
abrir os dispositivos por pessoas desconhecidas)
Reportar comportamentos suspeitos e indicaes de
adulterao ou substituio para a equipe apropriada (por
exemplo, para um gerente ou funcionrio da segurana).
Os criminosos frequentemente afirmam ser da
equipe de manuteno autorizada para obter
acesso aos dispositivos POS. Todos os terceiros
que solicitarem acesso aos dispositivos devem ser
sempre verificados antes de terem o acesso
concedido, por exemplo, verificando com o
gerenciamento ou telefonando para a empresa de
manuteno do POS (como o fornecedor ou
adquirente) para verificao. Muitos criminosos
tentaro enganar os funcionrios se vestindo para
a funo (por exemplo, carregando caixas de
ferramentas e vestidos com uniformes de trabalho)
e tambm podem saber sobre os locais dos
dispositivos, por isso importante que os
funcionrios sejam treinados para seguir sempre
os procedimentos.
Outro truque que os criminosos gostam de usar
enviar um "novo" sistema de POS com instrues
para troc-lo com o sistema legtimo e "devolver" o
sistema legtimo para um endereo especfico. Os
criminosos podem ainda oferecer a postagem de
retorno j que querem muito colocar suas mos
nestes dispositivos. Os funcionrios sempre
verificam com o gerente ou fornecedor se o
dispositivo legtimo e se veio de uma fonte
confivel antes de instal-lo ou us-lo para
negcios.
9.9.3.b Questione alguns funcionrios nos locais de ponto de
venda para verificar se ele receberam treinamento e se esto
cientes dos procedimentos para o seguinte:
Verificar a identidade de qualquer terceiro que alegue ser
da equipe de manuteno ou reparo, antes de conceder
acesso para modificar ou resolver problemas nos
dispositivos
No instalar, substituir ou devolver dispositivos sem
verificao
Estar atento a comportamentos suspeitos ao redor dos
dispositivos (por exemplo, tentativas de desconectar ou
abrir os dispositivos por pessoas desconhecidas)
Reportar comportamentos suspeitos e indicaes de
adulterao ou substituio para a equipe apropriada (por
exemplo, para um gerente ou funcionrio da segurana).
para restringir o acesso fsico aos dados
do portador do carto estejam
operacionais para restringir o acesso fsico aos dados do portador
do carto esto:
Documentados,
Em uso, e
operacionais para restringir o acesso fsico dos
dados do portador do carto e sistemas CDE
continuamente.

Monitorar e testar as redes regularmente
Requisito 10: Acompanhe e monitore todos os acessos com relao aos recursos da rede e aos dados do portador do
carto
Mecanismos de registro e a capacidade de monitorar as atividades dos usurios so fundamentais na preveno, deteco ou minimizao do
impacto do comprometimento dos dados. A presena de registros em todos os ambientes permite o monitoramento, o alerta e a anlise completa
quando algo d errado. Determinar a causa de um comprometimento muito difcil, se no impossvel, sem registros das atividades do sistema.
10.1 Implemente trilhas de auditoria para
ligar todos os acessos aos componentes
do sistema para cada usurio individual.
10.1 Verifique, atravs da observao e questionando o
administrador do sistema, se:
Trilhas de auditoria esto habilitadas e ativas para os
componentes do sistema.
O acesso aos componentes do sistema est ligado aos
usurios individuais.
essencial ter um processo ou sistema que
vincule o acesso do usurio aos componentes do
sistema acessados. Esse sistema gera logs de
auditoria e oferece a capacidade de rastrear as
atividades suspeitas de um usurio especfico.
10.2 Implemente trilhas de auditoria
automatizadas para todos os
componentes do sistema para recuperar
os seguintes eventos:
10.2 Por meio de entrevistas do funcionrio responsvel,
observao de registros de auditoria e anlise de suas
configuraes, desempenhe o seguinte:
Gerar trilhas de auditoria de atividades suspeitas
alerta o administrador do sistema, envia dados a
outros mecanismos de monitoramento (como
sistemas de deteco de intruso) e fornece uma
trilha do histrico para acompanhamento ps-
acidente. Registrar os seguintes eventos permite
que uma empresa identifique e rastreie atividades
potencialmente mal-intencionadas
10.2.1 Todos os acessos de usurios
individuais aos dados do portador do
carto
10.2.1 Verifique se todos os acessos individuais aos dados do
portador do carto esto registrados.
Indivduos mal-intencionados poderiam tomar
conhecimento de uma conta de usurio com
acesso aos sistemas no CDE ou poderiam criar
uma conta nova, no autorizada, para acessar os
dados do portador do carto. Um registro de
todos os acessos individuais para os dados do
portador do carto pode identificar quais contas
podem ter sido comprometidas ou usadas
inadequadamente.

10.2.2 Todas as aes
desempenhadas por qualquer pessoa
com privilgios raiz ou administrativos
10.2.2 Verifique se todas as aes desempenhadas por qualquer
pessoa com privilgios raiz ou administrativos so registradas.
Contas com privilgios maiores, como
"administrador" ou "raiz", tm o potencial para
impactar fortemente a segurana ou a
funcionalidade operacional de um sistema. Sem o
registro das atividades executadas, uma empresa
no capaz de rastrear qualquer problema
resultante de algum erro administrativo ou uso
inadequado de privilgios em uma ao ou
indivduo especfico.
10.2.3 Acesso a todas as trilhas de
auditoria
10.2.3 Verifique se o acesso a todas as trilhas de auditoria
registrado.
Usurios mal-intencionados tentam
frequentemente alterar os registros de auditoria
para ocultar suas aes e um registro de acesso
permite que uma empresa rastreie quaisquer
inconsistncias ou potenciais adulteraes dos
registros para uma conta individual. Ter acesso
aos registros que identificam alteraes, adies
e excluses pode ajudar a reconstituir os passos
feitos pelo pessoal no autorizado.
10.2.4 Tentativas invlidas de acesso
lgico
10.2.4 Verifique se as tentativas invlidas de acesso lgico esto
registradas.
Indivduos mal-intencionados na rede muitas
vezes executam vrias tentativas de acesso nos
sistemas alvejados. Vrias tentativas invlidas de
logon podem ser um indicador de tentativas de
um usurio no autorizado "forar" ou adivinhar
uma senha.
10.2 5 O uso e alteraes dos
mecanismos de identificao e
autenticao, incluindo, entre outros, a
criao de novas contas e aumento de
privilgios e todas as alteraes,
adies ou excluses de contas com
privilgios raiz ou administrativos
10.2.5.a Verifique se o uso dos mecanismos de identificao e
autenticao registrado.
Sem saber quem estava registrado no momento
de um incidente, impossvel identificar as contas
que possam ter sido usadas. Alm disso, usurios
mal-intencionados tentam manipular os controles
de autenticao com o objetivo de contorn-los
ou imitar uma conta vlida.
10.2.5.b Verifique se todos os aumentos de privilgios so
registrados.
10.2.5.c Verifique se todas as alteraes, adies ou excluses
em qualquer conta com privilgios raiz ou administrativos so
registradas.

10.2.6 Inicializao, interrupo ou
pausa dos registros de auditoria
10.2.6 Verifique se o que segue registrado:
Inicializao dos logs de auditoria
Interrupo ou pausa dos registros de auditoria.
Desativar os logs de auditoria (ou paus-los)
antes de realizar atividades ilcitas uma prtica
comum a usurios mal-intencionados que
desejam evitar ser detectados. A inicializao dos
logs de auditoria podem indicar que a funo de
registro foi desativada por um usurio para ocultar
suas aes.
10.2.7 Criao e excluso de objetos
do nvel do sistema
10.2.7 Verifique se a criao e a excluso de objetos do nvel do
sistema so registrados.
Softwares mal-intencionados, como malwares,
frequentemente criam ou substituem objetos no
nvel do sistema no sistema de destino para
controlar uma funo ou operao nesse sistema.
Registrando quando os objetos do nvel do
sistema, como tabelas do banco de dados ou
procedimentos armazenados, so criados ou
excludos, ser mais fcil determinar se estas
modificaes foram autorizadas.
10.3 Registre pelo menos as seguintes
entradas de trilhas de auditoria para
todos os componentes do sistema para
cada evento:
10.3 Por meio de entrevistas e da observao dos logs de
auditoria, para cada evento auditvel (no item 10.2), realize o
seguinte:
Ao registrar esses detalhes para os eventos
auditveis em 10.2, um possvel
comprometimento poder ser rapidamente
identificado e com detalhes suficientes para saber
quem, o que, onde, quando e como.
10.3.1 Identificao do usurio 10.3.1 Verifique se a identificao do usurio est includa nas
entradas do registro.
10.3.2 Tipo de evento 10.3.2Verifique se o tipo de evento est includo nas entradas do
registro.
10.3.3 Data e horrio 10.3.3Verifique se a data e o horrio esto includos nas
10.3.4 Indicao de sucesso ou falha 10.3.4Verifique se a indicao de xito ou falha est includa nas
10.3.5 Origem do evento 10.3.5Verifique se a origem do evento est includa nas entradas
do registro.
10.3.6 A identidade ou o nome dos
dados afetados, componentes do
sistema ou recurso.
10.3.6Verifique se a identidade ou o nome dos dados afetados,
os componentes do sistema ou recursos esto includos nas

10.4 Usando tecnologia de sincronizao
de tempo, sincronize todos os relgios e
horrios crticos do sistema e assegure-
se de que os seguintes itens sejam
implementados para adquirir, distribuir e
armazenar horrios.
Observao: Um exemplo de tecnologia
de sincronizao de horrios o
Network Time Protocol (NTP).
10.4 Analise os processos e padres de configurao para
verificar se a tecnologia de sincronizao de tempo est
implementada e mantida atualizada pelos Requisitos 6.1 e 6.2 do
PCI DSS.
A tecnologia para sincronizao do horrio
usada para sincronizar os relgios. Quando os
relgios no so sincronizados adequadamente
pode ser difcil, se no impossvel, comparar
arquivos de registro de diferentes sistemas e
estabelecer uma sequncia exata de eventos
(cruciais para anlise forense no caso de uma
violao). Para equipes de forenses ps-
incidente, a preciso e a consistncia do horrio
ao longo de todos os sistemas e a hora de cada
atividade so essenciais para determinar a forma
como os sistemas foram comprometidos.
10.4.1 Sistemas crticos tm o horrio
correto e consistente.
10.4.1.a Analise o processo para a aquisio, distribuio e
armazenamento do horrio correto na empresa para verificar se:
Apenas os servidores centrais de horrio designados
recebem sinais de horrio de fontes externas e se os sinais
de horrio de fontes externas so baseadas no Tempo
Atmico Internacional ou no UTC.
Onde houver mais de um servidor de horrio designado, os
servidores de horrios se igualam um com o outro para
manter a hora exata.
Os sistemas recebem informaes de horrio somente dos
servidores centrais de horrio designados.
10.4.1.b Observe as configuraes dos parmetros do sistema
relacionadas ao horrio para obter uma amostra dos
componentes do sistema e verificar se:
Apenas os servidores centrais de horrio designados
recebem sinais de horrio de fontes externas e se os sinais
de horrio de fontes externas so baseadas no Tempo
Atmico Internacional ou no UTC.
Onde houver mais de um servidor de horrio designado, os
servidores centrais de horrios designados se igualam um
com o outro para manter a hora exata.
Os sistemas recebem o horrio somente dos servidores
centrais de horrio designados.

10.4.2 Os dados de horrio so
protegidos.
10.4.2.a Analise as definies de configurao e de
sincronizao de horrio para verificar se o acesso aos dados de
horrio so restritos somente aos funcionrios com
necessidades comerciais de acesso aos dados de horrio.
10.4.2.b Analise as definies, registros e processos de
configurao e de sincronizao de horrio para verificar se
qualquer alterao s definies de horrio em sistemas crticos
registrada, monitorada e revisada.
10.4.3 As definies de horrio so
recebidas de fontes de horrio aceitas
pelo setor.
10.4.3 Analise as configuraes dos sistemas para verificar se
os servidores de horrio aceitam atualizaes de fontes externas
especficas, aceitas pelo setor (para evitar que um indivduo mal-
intencionado altere o relgio). Alm disso, essas atualizaes
podem ser criptografas com uma chave simtrica e as listas de
controle de acesso podem ser criadas para especificar os
endereos IP das mquinas clientes que sero fornecidas com
as atualizaes de horrio (para evitar o uso no autorizado de
servidores de horrio internos).
10.5 Proteja as trilhas de auditoria para
que no possam ser alteradas.
10.5 Questione os administradores do sistema e analise as
configuraes do sistema e permisses para verificar se as trilhas
de auditoria esto protegidas de forma que no possam ser
alteradas conforme segue:
Muitas vezes um indivduo mal-intencionado que
entra em uma rede tenta editar os logs de
auditoria para ocultar suas atividades. Sem
proteo adequada dos logs de auditoria, sua
concluso, preciso e integridade no podero
ser garantidas e os logs de auditoria podero ser
inutilizados como ferramenta de investigao
aps um comprometimento.
10.5.1 Limite a exibio de trilhas de
auditoria s pessoas que tm uma
necessidade relacionada funo.
10.5.1Apenas os indivduos que tm uma necessidade
relacionada funo podem visualizar arquivos de trilha de
auditoria.
Uma proteo adequada dos logs de auditoria
inclui forte controle de acesso (limitar o acesso
aos logs com base somente na necessidade de
divulgao) e uso da separao fsica e da rede
para deixar os logs mais difceis de serem
encontrados e modificados.
Fazer imediatamente o backup dos logs para um
servidor centralizado de log ou mdias que sejam
difceis de alterar mantm os registros protegidos
mesmo se o sistema que gera os registros for
comprometido.
10.5.2 Proteja os arquivos de trilha de
auditoria de modificaes no
autorizadas.
10.5.2 Os arquivos de trilha de auditoria atuais esto protegidos
de modificaes no autorizadas por meio de mecanismos de
controle de acesso, separao fsica e/ou separao da rede.
10.5.3 Faa imediatamente o backup
dos arquivos de trilha de auditoria em
um servidor de registros centralizado
ou mdias que sejam difceis de alterar.
10.5.3Os arquivos de trilha de auditoria atuais tm o backup feito
imediatamente em um servidor de registros centralizado ou
mdias que sejam difceis de alterar.

10.5.4 Documente registros quanto s
tecnologias externas em um servidor
de registros centralizado, seguro ou
dispositivo de mdia.
10.5.4Os registros quanto s tecnologias externas (por exemplo,
sem fio, firewalls, DNS, e-mail) so escritos em um servidor de
registro interno centralizado ou mdia seguros.
Ao gravar os logs de tecnologias que usam
recursos externos, como sem fio, firewalls, DNS e
servidores de e-mail, o risco de esses logs serem
perdidos ou alterados diminudo, pois eles esto
mais seguros dentro da rede interna.
Os logs podem ser escritos diretamente, ou
transferidos ou copiados de sistemas externos
para a mdia ou sistema interno seguros.
10.5.5 Use softwares de
monitoramento da integridade dos
arquivos ou de deteco de alteraes
nos logs para assegurar que os dados
de registro existentes no possam ser
alterados sem gerar alertas (embora
os novos dados que estejam sendo
adicionados no gerem um alerta).
10.5.5 Analise as configuraes do sistema, os arquivos e
resultados monitorados das atividades de monitoramento para
verificar o uso de software para monitoramento da integridade do
arquivo ou deteco de alteraes nos registros.
Os sistemas de monitoramento da integridade do
arquivo ou de deteco de alteraes verificam as
alteraes nos arquivos crticos e notificam
quando essas alteraes so observadas. Para
fins de monitoramento da integridade do arquivo,
uma entidade normalmente monitora os arquivos
que no mudam regularmente, mas que, quando
alterados, indicam um possvel comprometimento.
10.6 Revise os registros e ocorrncias
de segurana para todos os
componentes do sistema para identificar
irregularidades ou atividades suspeitas.
Observao: Ferramentas de coleta,
anlise e alerta dos logs podem ser
usadas para atender a este requisito.
10.6 Realize as seguintes etapas: Vrias violaes ocorrem durante dias ou meses
antes de serem detectadas. A verificao diria
dos logs minimiza a quantidade de tempo e
exposio de uma violao em potencial.
Revises regulares dos logs pelos funcionrios ou
meios automatizados podem identificar e resolver
proativamente o acesso no autorizado ao
ambiente de dados do portador do carto.
O processo de reviso do log no precisa ser
manual. O uso de ferramentas de coleta, anlise
e alertas pode facilitar o processo identificando as
ocorrncias de logs que precisam ser revisados.

10.6.1 Revise o que segue ao menos
diariamente:
Todas as ocorrncias de segurana
Logs de todos os componentes do
sistema que armazenam,
processam ou transmitem CHD
e/ou SAD, ou que possam impactar
na segurana do CHD e/ou SAD
Logs de todos os componentes
crticos do sistema
Registros de todos os servidores e
componentes do sistema que
desempenham funes de
segurana (por exemplo, firewalls,
sistemas de deteco de
invaso/sistemas de preveno
contra invaso (IDS/IPS),
servidores de autenticao,
servidores de redirecionamento do
e-commerce, etc.).
10.6.1.a Analise as polticas e os procedimentos de segurana
para verificar se esto definidos para revisar o que segue, pelo
menos diariamente, seja de forma manual ou por meio de
ferramentas de logs:
Logs de todos os componentes do sistema que armazenam,
processam ou transmitem CHD e/ou SAD, ou que possam
impactar na segurana do CHD e/ou SAD
Logs de todos os componentes crticos do sistema
Logs de todos os servidores e componentes do sistema que
desempenham funes de segurana (por exemplo,
firewalls, sistemas de deteco de invaso/sistemas de
preveno contra invaso (IDS/IPS), servidores de
autenticao, servidores de redirecionamento do e-
commerce, etc.)
Vrias violaes ocorrem durante dias ou meses
antes de serem detectadas. A verificao diria
dos logs minimiza a quantidade de tempo e
exposio de uma violao em potencial.
A reviso diria de ocorrncias de segurana, por
exemplo, avisos ou alertas que identificam
atividades irregulares ou suspeitas, bem como
registros dos componentes crticos do sistema e
registros dos sistemas que desempenham
funes de segurana, como firewalls, IDS/IPS,
sistemas de monitoramento da integridade do
arquivo (FIM), etc., necessria para identificar
possveis problemas. Observe que a
determinao de "ocorrncia de segurana" varia
para cada organizao e pode considerar o tipo
de tecnologia, local e funo do dispositivo. As
organizaes tambm podem manter um
parmetro do trfego "normal" para ajudar a
identificar comportamentos irregulares.

10.6.1.b Observe os processos e questione os funcionrios para
verificar se o que segue revisado, ao menos diariamente:
Logs de todos os componentes do sistema que armazenam,
processam ou transmitem CHD e/ou SAD, ou que possam
impactar na segurana do CHD e/ou SAD
Logs de todos os componentes crticos do sistema
Registros de todos os servidores e componentes do sistema
que desempenham funes de segurana (por exemplo,
firewalls, sistemas de deteco de invaso/sistemas de
preveno contra invaso (IDS/IPS), servidores de
autenticao, servidores de redirecionamento do e-
commerce, etc.).
10.6.2 Revise os logs de todos os
outros componentes do sistema
periodicamente com base nas polticas
e estratgia de gerenciamento de risco
da organizao, conforme determinado
pela avaliao de risco anual da
para verificar se esto definidos procedimentos para revisar os
logs de todos os outros componentes do sistema
periodicamente, seja de forma manual ou por meio de
ferramentas de logs, com base nas polticas e estratgia de
gerenciamento de risco da organizao.
Os logs para todos os outros componentes do
sistema tambm devem ser revisados
periodicamente para identificar indicaes de
possveis problemas ou tentativas de obter
acesso aos sistemas confidenciais por meio de
sistemas menos confidenciais. A frequncia de

organizao.
10.6.2.b Analise a documentao da avaliao de risco da
organizao e questione os funcionrios para verificar se as
revises so realizadas de acordo com as polticas e estratgia
de gerenciamento de risco da organizao.
revises deve ser determinada por uma avaliao
de risco anual da entidade.
10.6.3 Acompanhe as excees e
irregularidades identificadas durante o
processo de reviso.
para verificar se esto definidos procedimentos para
acompanhar as excees e irregularidades identificadas durante
o processo de reviso.
Se as excees e irregularidades identificadas
durante o processo de reviso do registro no
forem investigadas, a entidade pode no tomar
conhecimento de atividades no autorizadas e
potencialmente mal-intencionadas que estejam
ocorrendo dentro de sua prpria rede.
10.6.3.b Observe os processos e questione os funcionrios para
verificar se so realizados acompanhamentos das excees e
irregularidades.
10.7 Mantenha um histrico da trilha de
auditoria por pelo menos um ano, com
um mnimo de trs meses
imediatamente disponvel para anlise
(por exemplo, online, arquivado ou
recupervel a partir do backup).
10.7.a Analise as polticas e procedimentos de segurana para
verificar se eles definem o que segue:
Polticas de manuteno de log de auditoria
Procedimentos para manter logs de auditoria por pelo menos
um ano, com um mnimo de trs meses imediatamente
disponvel online.
Guardar os logs por pelo menos um ano leva em
conta o fato de muitas vezes se levar um tempo
at notar que ocorreu ou est ocorrendo um
comprometimento e permite que os
investigadores tenham um histrico de log
suficiente para determinar melhor a quantidade
de tempo de uma potencial violao e os
possveis sistemas afetados. Ao ter trs meses de
logs imediatamente disponveis, uma entidade
pode rapidamente identificar e minimizar o
impacto da violao de dados. O armazenamento
de logs em locais offline pode evitar que eles
fiquem prontamente disponveis, resultando em
cronogramas mais longos para restaurar dados
de log, executar anlises e identificar sistemas ou
dados afetados.
10.7.b Questione os funcionrios e analise os logs de auditoria
para verificar se eles esto disponveis por pelo menos um ano.
10.7.c Questione os funcionrios e observe os processos para
verificar se os registros dos ltimos trs meses podem ser
armazenados imediatamente para anlise.
para monitoramento de todos os
acessos aos recursos e dados do
portador do carto estejam
operacionais para monitorar todos os acessos aos recursos de
rede e dados do portador do carto esto:
Documentados,
Em uso, e
operacionais dirios para monitorar todos os
acessos aos recursos de rede e dados do
portador do carto continuamente.

Requisito 11: Testar regularmente os sistemas e processos de segurana.
As vulnerabilidades esto sendo continuamente descobertas por indivduos mal-intencionados e pesquisadores e so apresentadas por novos
softwares. Os componentes do sistema, processos e softwares personalizados devem ser testados com frequncia para assegurar que os
controles de segurana continuem refletindo um ambiente em transformao.
11.1 Implemente processos para testar a
presena de pontos de acesso sem fio
(802.11) e detectar e identificar todos os
pontos de acesso sem fio autorizados e
no autorizados trimestralmente.
Observao: Mtodos que podem ser
usados no processo incluem, entre outros,
varreduras de rede sem fio, inspees
fsicas/virtuais de componentes e
infraestrutura do sistema, controle de
acesso rede (NAC) ou IDS/IPS sem fio.
Qualquer mtodo usado deve ser suficiente
para detectar e identificar dispositivos
autorizados e no autorizados.
11.1.a Analise as polticas e procedimentos para verificar se
esto definidos processos para detectar e identificar pontos
de acesso sem fio autorizados e no autorizados
trimestralmente.
A implementao e/ou explorao da tecnologia
sem fio dentro de uma rede um dos caminhos
mais comuns para usurios mal-intencionados
obterem acesso rede e aos dados do portador
do carto. Se um dispositivo sem fio ou uma rede
forem instalados sem o conhecimento da empresa,
ele pode permitir que um invasor entre na rede de
forma fcil e invisvel. Dispositivos sem fio no
autorizados devem ser ocultados ou anexados a
um computador ou outro componente do sistema,
ou ser anexados diretamente a uma porta ou
dispositivo da rede, como um switch ou roteador.
Qualquer desses dispositivos no autorizados
podem resultar em um ponto no autorizado de
acesso ao ambiente.
Saber quais dispositivos sem fio so autorizados
pode ajudar os administradores a identificar mais
rapidamente os dispositivos sem fio no
autorizados e reagir identificao de pontos de
acesso sem fio no autorizados ajuda a minimizar
proativamente a exposio do CDE a indivduos
mal-intencionados.
Em funo da facilidade com que o ponto de
acesso sem fio pode ser conectado a uma rede,
da dificuldade em detectar sua presena e do risco
cada vez maior apresentado por dispositivos sem
fio no autorizados, esses processos devem ser
executados at quando existir uma poltica
proibindo o uso da tecnologia sem fio.
O tamanho e a complexidade de um ambiente
privado determinaro as ferramentas e os
processos adequados a serem usados para
11.1.b Verifique se a metodologia adequada para detectar e
identificar qualquer ponto de acesso sem fio no autorizado,
incluindo ao menos o seguinte:
Cartes WLAN inseridos nos componentes do sistema
Dispositivos mveis ou portteis fixados a componentes
do sistema para criar um ponto de acesso sem fio (por
exemplo, por USB, etc.)
Dispositivos sem fio conectados a uma porta de rede ou a
um dispositivo de rede.
11.1.c Analise os resultados de varreduras sem fio recentes
para verificar se:
Os pontos de acesso sem fio autorizados e no
autorizados esto identificados, e
A varredura realizada ao menos trimestralmente para
todas as instalaes e componentes do sistema.
11.1.d Se o monitoramento automatizado for utilizado (por
exemplo, IDS/IPS sem fio, NAC, etc.), verifique que a
configurao gerar alertas para avisar os funcionrios.

fornecer garantia suficiente de que um ponto de
acesso sem fio intruso no tenha sido instalado no
ambiente.
11.1.1 Mantenha um inventrio de pontos
de acesso sem fio autorizados incluindo
uma justificativa comercial documentada.
11.1.1 Analise os registros documentados para verificar se
mantido um inventrio de pontos de acesso sem fio
autorizados e se uma justificativa comercial est
documentada para todos os pontos de acesso sem fio
autorizados.
Por exemplo: No caso de um nico quiosque de
revenda autnomo em um shopping, onde todos
os componentes de comunicao esto contidos
em estojos antiadulterao e indicadores de
adulterao, executando inspees fsicas
detalhadas no prprio quiosque pode ser suficiente
para fornecer garantias de que nenhum ponto de
acesso sem fio intruso foi anexado ou instalado.
No entanto, em um ambiente com vrios ns
(como em uma grande loja de revenda, uma
central de atendimento, sala de servidor ou centro
de dados), a inspeo fsica detalhada difcil.
Nesse caso, vrios mtodos podem ser
combinados para atender ao requisito, como
executar inspees fsicas no sistema em conjunto
com os resultados de um analisador sem fio.
11.1.2 Implemente procedimentos de
resposta a incidentes para o caso de
serem detectados pontos de acesso sem
fio no autorizados.
11.1.2.a Analise o plano de resposta a incidentes da
organizao (Requisito 12.10) para verificar se ele define e
exige uma reao no caso de ser detectado um ponto de
acesso sem fio no autorizado.
11.1.2.b Questione os funcionrios responsveis e/ou
inspecione as varreduras sem fio recentes e as respostas
relacionadas para verificar se a ao realizada quando
pontos de acesso sem fio no autorizados so encontrados.

11.2 Execute varreduras quanto s
vulnerabilidades das redes internas e
externas pelo menos trimestralmente e
aps qualquer mudana significativa na
rede (como instalaes de novos
componentes do sistema, mudanas na
topologia da rede, modificaes das
normas do firewall, aprimoramentos de
produtos).
Observao: Vrios relatrios de
varredura podem ser combinados no
processo de varredura trimestral para
mostrar que todos os sistemas foram
mapeados e que todas as vulnerabilidades
aplicveis foram resolvidas. Pode ser
exigida uma documentao adicional para
verificar se as vulnerabilidades no
resolvidas esto em processo de serem
solucionadas.
Para a conformidade inicial com o PCI
DSS, no necessrio que as quatro
varreduras trimestrais aprovadas sejam
concludas se o assessor verificar que 1) o
resultado da varredura mais recente foi
uma varredura aprovada, 2) a entidade
possui polticas e procedimentos
documentados que requerem a sequncia
de varreduras trimestrais e 3) as
vulnerabilidades observadas nos
resultados da varredura tenham sido
corrigidas conforme mostrado em uma
nova varredura. Nos anos seguintes aps a
anlise inicial do PCI DSS, quatro
varreduras trimestrais aprovadas devem ter
ocorrido.
11.2 Analise os relatrios de varredura e documentao de
suporte para verificar se as varreduras de vulnerabilidades
internas e externas so realizadas conforme segue:
Uma varredura de vulnerabilidade uma
ferramenta automatizada executada em
dispositivos de rede interna e externa e servidores,
feita para expor possveis vulnerabilidades que
possam ser encontradas e exploradas por
indivduos mal-intencionados.
H trs tipos de varredura de vulnerabilidades
exigidas para o PCI DSS:
Varredura interna de vulnerabilidades trimestral
feita por funcionrios qualificados (o uso de um
Fornecedor de Varredura Aprovado (ASV) para
o PCI SSC no necessrio)
Varredura externa de vulnerabilidades
trimestral, a qual deve ser realizada por um
ASV
Varredura interna e externa conforme
necessrio aps mudanas significativas
Quando esses pontos fracos so identificados, a
entidade os corrige e repete a varredura at que
todas as vulnerabilidades tenham sido corrigidas.
Identificar e resolver as vulnerabilidades em tempo
hbil reduz as chances de explorao de uma
vulnerabilidade e o comprometimento potencial de
um componente do sistema ou de dados do
portador do carto.

11.2.1 Realize varreduras internas de
vulnerabilidades trimestralmente e novas
varreduras conforme necessrio, at que
todas as vulnerabilidades de "alto-risco"
(identificadas no requisito 6.1) sejam
resolvidas. As varreduras devem ser
realizadas por uma equipe qualificada.
11.2.1.a Analise os relatrios de varredura e verifique se
ocorreram quatro varreduras internas trimestrais nos
ltimos 12 meses.
Um processo estabelecido para identificar
vulnerabilidades em sistemas internos exige que
as varreduras de vulnerabilidade sejam
conduzidas trimestralmente. As vulnerabilidades
que representam o maior risco ao ambiente (por
exemplo, classificadas como "Alto" pelo requisito
6.1) deve ser resolvida com a maior prioridade.
Varreduras de vulnerabilidade internas podem ser
realizadas por profissionais internos e qualificados
que sejam razoavelmente independentes dos
componentes do sistema que esto sendo
mapeados (por exemplo, um administrador de
firewall no deve ser responsvel pela varredura
do firewall), ou a entidade pode optar por fazer as
varreduras de vulnerabilidade internas por uma
empresa especializada em varreduras de
vulnerabilidade.
11.2.1.b Analise os relatrios de varredura e verifique se o
processo inclui novas varreduras at que todas as
vulnerabilidades de "alto risco", conforme definidas no
requisito 6.1 do PCI DSS, estejam solucionadas.
11.2.1.c Questione os funcionrios para verificar se a
varredura foi realizada por um recurso interno qualificado ou
um terceiro externo qualificado e, caso seja aplicvel, se h
uma independncia organizacional do responsvel pelo
teste (no necessrio que seja um QSA ou ASV).
11.2.2 Realize varreduras externas
trimestrais de vulnerabilidades por meio
de um Fornecedor de Varreduras
Aprovado (ASV) qualificado pelo
Conselho de padres de segurana da
Indstria de cartes de pagamento (PCI
SSC). Realiza novas varreduras
conforme necessrio, at que se chegue
a varreduras aprovadas.
Observao: As varreduras externas
trimestrais de vulnerabilidades devem ser
realizadas por um Fornecedor de
Varreduras Aprovado (ASV) qualificado
pelo Conselho de padres de segurana
da Indstria de cartes de pagamento (PCI
SSC).
Consulte o Guia do programa ASV
publicado no site do PCI SSC para saber
sobre responsabilidades de varredura do
cliente, preparao de varredura, etc.
11.2.2.a Revise o resultado das varreduras externas de
vulnerabilidades dos quatro ltimos trimestres e verifique se
ocorreram quatro varreduras nos ltimos 12 meses.
Como redes externas tm um risco maior de
comprometimento, a varredura de vulnerabilidade
externa trimestral deve ser realizada por um
Fornecedor de Varreduras Aprovado (ASV) do PCI
SSC.
11.2.2.b Analise os resultados de cada varredura trimestral
e de novas varreduras para verificar se elas atendem aos
requisitos do Guia do programa ASV (por exemplo,
nenhuma vulnerabilidade classificada com mais de 4.0 pelo
CVSS e sem falhas automticas).
11.2.2.c Revise os relatrios de varredura para verificar se
as varreduras foram concludas por um Fornecedor de
Varredura Aprovado (ASV) pelo PCI SSC.

11.2.3 Realize varreduras internas e
externas e novas varreduras se
necessrio, aps qualquer mudana
significativa. As varreduras devem ser
realizadas por uma equipe qualificada.
11.2.3.a Inspecione correlacione a documentao do
controle de alteraes e realize uma varredura nos
relatrios para verificar se os componentes do sistema
sujeitos a qualquer alterao significativa passaram por
varredura.
A determinao do que constitui uma alterao
significativadepende muito da configurao de
um determinado ambiente. Se uma melhoria ou
modificao puder permitir o acesso aos dados do
portador do carto ou afetar a segurana do
ambiente de dados do portador do carto, ela
pode ser considerada significativa.
Mapear um ambiente depois de qualquer alterao
significativa ter sido feita garante que todas as
alteraes foram concludas adequadamente para
que a segurana do ambiente no tenha sido
comprometida como resultado da alterao. Todos
os componentes do sistema afetados pela
alterao precisam passar por varredura.
11.2.3.b Analise os relatrios de varredura e verifique se o
processo inclui novas varreduras at que:
No existam varreduras com pontuao maior do que
4.0 pelo CVSS para varreduras externas.
Todas as vulnerabilidades de "alto risco", conforme
definidas no requisito 6.1 do PCI DSS, estejam
solucionadas para varreduras internas.
11.2.3.c Verifique se a varredura foi realizada por um
recurso interno qualificado ou um terceiro externo
qualificado e, caso seja aplicvel, se h uma independncia
organizacional do responsvel pelo teste (no necessrio
que seja um QSA ou ASV).

11.3Implemente uma metodologia para
testes de penetrao que inclua o seguinte:
baseada nas abordagens de testes
de penetrao aceitas pelo setor (por
exemplo, NIST SP800-115)
Abrange todo o permetro do CDE e
sistemas crticos
Inclui testes de dentro e fora da rede
Inclui testes para validar qualquer
controle de reduo no escopo e
segmentao
Define testes de penetrao da camada
do aplicativo para incluir, pelo menos,
as vulnerabilidades listadas no requisito
6.5.
Define testes de penetrao da camada
da rede que incluam componentes
11.3 Analise a metodologia de testes de penetrao e
questione o funcionrio responsvel para verificar se est
implementada uma metodologia que inclua o seguinte:
baseada nas abordagens de testes de penetrao
aceitas pelo setor (por exemplo, NIST SP800-115)
Abrange todo o permetro do CDE e sistemas crticos
Testes de dentro e fora da rede
Inclui testes para validar qualquer controle de reduo no
escopo e segmentao
Define testes de penetrao da camada do aplicativo para
incluir, pelo menos, as vulnerabilidades listadas no
requisito 6.5.
Define testes de penetrao da camada da rede que
incluam componentes compatveis com as funes da
rede e com os sistemas operacionais.
Inclui reviso e considerao de ameaas e
vulnerabilidades ocorridas nos ltimos 12 meses
O objetivo de um teste de penetrao estimular
uma situao de invaso real com o objetivo de
identificar at onde um invasor conseguiria
penetrar em um ambiente. Isso permite que a
entidade tenha mais compreenso sobre sua
potencial exposio e desenvolva uma estratgia
para se defender de invases.
Um teste de penetrao difere de uma varredura
de vulnerabilidade, uma vez que o teste de
penetrao um processo ativo que pode incluir a
explorao de vulnerabilidades identificadas.
Conduzir uma varredura de vulnerabilidade pode
ser um dos primeiros passos que um testador de
penetrao realizar para planejar uma estratgia
de teste, mesmo que no seja o nico passo.
Mesmo que uma varredura de vulnerabilidade no
detecte nenhuma vulnerabilidade conhecida, o
testador de penetrao ir normalmente tomar

compatveis com as funes da rede e
com os sistemas operacionais.
Inclui reviso e considerao de
ameaas e vulnerabilidades ocorridas
nos ltimos 12 meses
Especifica a conservao dos
resultados de testes de penetrao e
resultados de atividades de reparo.
Observao: Esta atualizao do requisito
11.3 considerada uma das melhores
prticas at 30 de junho de 2015 quando
passar a ser um requisito. Os requisitos
do PCI DSS v2.0 para testes de
penetrao devem ser seguidos at que a
v3.0 esteja vigente.
Especifica a conservao dos resultados de testes de
penetrao e resultados de atividades de reparo.
conhecimento suficiente sobre o sistema para
identificar possveis lacunas de segurana.
O teste de penetrao geralmente um processo
altamente manual. Enquanto algumas ferramentas
automatizadas podem ser usadas, o testador
utiliza seu conhecimento de sistemas para
penetrar em um ambiente. Normalmente o
testador ir conectar diversos tipos de exploraes
com o objetivo de ultrapassar camadas de
defesas. Por exemplo, se o testador encontrar
meios de obter acesso a um servidor de aplicativo,
em seguida ele usar o servidor comprometido
como um ponto de preparao para uma nova
invaso com base nos recursos a que o servidor
tem acesso. Dessa forma, o testador capaz de
simular os mtodos utilizados por um invasor para
identificar reas de fraquezas potenciais no
ambiente.
As tcnicas de teste de penetrao sero
diferentes para diferentes organizaes e o tipo,
profundidade e complexidade do teste depender
do ambiente especfico e da avaliao de risco da
organizao.
11.3.1 Realize testes de penetrao
externos pelo menos uma vez ao ano e
aps qualquer melhoria ou modificao
significativa na infraestrutura ou nos
aplicativos (como uma melhoria no
sistema operacional, uma sub-rede
adicionada ao ambiente ou um servidor
Web adicionado ao ambiente).
11.3.1.a Analise o escopo do trabalho e os resultados do
teste de penetrao mais recente para verificar se os testes
de penetrao so realizados conforme segue:
De acordo com a metodologia definida
Pelo menos uma vez ao ano
Aps quaisquer alteraes significativas no ambiente.
O teste de penetrao conduzido regularmente e
aps mudanas significativas no ambiente uma
medida de segurana proativa que ajuda a
minimizar o possvel acesso ao CDE por
indivduos mal-intencionados.
A determinao do que constitui uma melhoria ou
modificao significativa depende muito da
configurao de um determinado ambiente. Se
uma melhoria ou modificao puder permitir o
acesso aos dados do portador do carto ou afetar
a segurana do ambiente de dados do portador do
carto, ela pode ser considerada significativa.
Realizar testes de penetrao aps melhorias e
modificaes da rede garante que os controles
supostamente implementados ainda estejam
11.3.1.b Verifique se o teste foi realizado por um recurso
interno qualificado ou um terceiro externo qualificado e,
caso seja aplicvel, se h uma independncia
11.3.2 Realize testes de penetrao
internos pelo menos uma vez ao ano e
11.3.2.a Analise o escopo do trabalho e os resultados do
teste de penetrao mais recente para verificar se os testes

aps qualquer melhoria ou modificao
significativa na infraestrutura ou nos
aplicativos (como uma melhoria no
sistema operacional, uma sub-rede
adicionada ao ambiente ou um servidor
Web adicionado ao ambiente).
de penetrao so realizados pelo menos uma vez ao ano
e aps quaisquer mudanas significativas no ambiente.
De acordo com a metodologia definida
Pelo menos uma vez ao ano
Aps quaisquer alteraes significativas no ambiente.
funcionando efetivamente aps a melhoria ou
modificao.
11.3.2.b Verifique se o teste foi realizado por um recurso
interno qualificado ou um terceiro externo qualificado e,
caso seja aplicvel, se h uma independncia
11.3.3 As vulnerabilidades explorveis
encontradas durante o teste de
penetrao so corrigidas e o teste
repetido para verificar as correes.
11.3.3 Analise os resultados do teste de penetrao para
verificar se as vulnerabilidades explorveis observadas
foram corrigidas e se o teste repetido confirmou que ela foi
corrigida.

11.3.4 Se for utilizada a segmentao
para isolar o CDE de outras redes,
realize testes de penetrao ao menos
uma vez por ano e aps qualquer
alterao nos mtodos/controles de
segmentao para verificar se os
mtodos so operacionais e efetivos e se
isolam todos os sistemas fora do escopo
dos sistemas dentro do escopo.
11.3.4.a Analise os controles de segmentao e revise a
metodologia de teste de penetrao para verificar se os
procedimentos do teste so definidos para testar todos os
mtodos de segmentao para confirmar que eles so
operacionais e efetivos e isolar todos os sistemas fora do
escopo dos sistemas dentro do escopo.
O teste de penetrao uma ferramenta
importante para confirmar se qualquer
segmentao implantada para isolar o CDE de
outras redes efetiva. O teste de penetrao deve
focar nos controles da segmentao, tanto de
dentro quanto de fora da rede da entidade, mas
fora do CDE, para confirmar que eles no podem
passar pelos controles da segmentao para
acessar o CDE. Por exemplo, teste de rede e/ou
varredura para portas abertas, para verificar se
no h nenhuma conectividade entre as redes de
fora e dentro do escopo.
11.3.4.b Analise os resultados do teste de penetrao mais
recente para verificar se este teste dos controles de
segmentao:
executado pelo menos uma vez ao ano e aps
qualquer mudana nos mtodos/controles da
segmentao.
Abrange todos os mtodos/controles da segmentao
em uso.
Verifica se os mtodos de segmentao so
operacionais e efetivos e se isolam todos os sistemas
de fora do escopo dos sistemas de dentro do escopo.
11.4 Use tcnicas de deteco de invaso
e/ou preveno contra invases para
detectar e/ou evitar invases na rede.
Monitore todo o trfego no permetro do
ambiente de dados do portador do carto,
bem como nos pontos crticos do ambiente
e alerte as equipes sobre
comprometimentos suspeitos.
Mantenha todos os mecanismos de
deteco e preveno contra invases,
diretrizes e assinaturas atualizados.
11.4.a Analise as configuraes do sistema e diagramas da
rede para verificar se as tcnicas (como sistemas de
deteco e/ou preveno contra invases) esto
implementadas para monitorar todo o trfego:
No permetro do ambiente dos dados do portador do
carto
Nos pontos crticos do ambiente dos dados do portador do
carto.
As tcnicas de deteco e/ou preveno contra
invases (como IDS/IPS) comparam o trfego que
entra na rede com assinaturasconhecidas e/ou
comportamentos de milhares de tipos de
comprometimento (ferramentas de hacker, trojans
e outros tipos de malware) e envia alertas e/ou
interrompe a tentativa enquanto ela est
acontecendo. Sem uma abordagem proativa a
uma deteco de atividade no autorizada,
invases (ou mau uso) de recursos de computador
podem passar despercebidas em tempo real. Os
alertas de segurana gerados por essas tcnicas
devem ser monitorados, de forma que as
tentativas de invaso possam ser interrompidas.
11.4.b Analise as configuraes do sistema e questione os
funcionrios responsveis para confirmar se as tcnicas de
deteco e/ou preveno contra invaso alertam os
funcionrios de comprometimentos suspeitos.
11.4.c Analise as configuraes de IDS/IPS e a
documentao do fornecedor para verificar se as tcnicas de
deteco e/ou preveno contra invaso esto configuradas,
mantidas e atualizadas de acordo com as instrues do
fornecedor para assegurar uma proteo ideal.

11.5 Implemente um mecanismo de
deteco de alteraes (por exemplo,
ferramentas de monitoramento da
integridade do arquivo) para alertar a
equipe sobre modificaes no autorizadas
de arquivos crticos do sistema, arquivos
de configurao ou arquivos de contedo;
e configure o software para realizar
comparaes de arquivos crticos pelo
menos uma vez por semana.
Observao: Para fins de deteco de
alteraes, os arquivos crticos
normalmente so aqueles que no so
alterados com frequncia, mas sua
modificao poderia indicar um
comprometimento do sistema ou um risco
de comprometimento. Os mecanismos de
deteco de alteraes, como produtos de
monitoramento da integridade dos
arquivos, normalmente vm pr-
configurados com arquivos crticos para o
sistema operacional relacionado. Outros
arquivos crticos, como aqueles para os
aplicativos personalizados, devem ser
avaliados e definidos pela entidade (ou
seja, o comerciante ou prestador de
servios).
11.5.a Verifique o uso de um mecanismo de deteco de
alteraes no ambiente de dados do portador do carto
observando as configuraes do sistema e os arquivos
monitorados, bem como analisando os resultados das
atividades de monitoramento.
Exemplos de arquivos que devem ser monitorados:
Executveis do sistema
Executveis dos aplicativos
Arquivos de configurao e parmetro
Arquivos de log e auditoria, histricos ou arquivados,
armazenados centralmente
Arquivos crticos adicionais determinados pela entidade
(por exemplo, por meio de avaliao de risco ou outros
meios).
As solues de deteco de alteraes, como
ferramentas de monitoramento da integridade do
arquivo (FIM), verificam as alteraes nos arquivos
crticos e notificam quando essas alteraes so
detectadas. Se no implementadas corretamente e
se o resultado da soluo de deteco de
alteraes no for monitorado, um indivduo mal-
intencionado pode alterar o contedo do arquivo
de configurao, os programas do sistema
operacional ou os executveis do aplicativo.
Alteraes no autorizadas, se no detectadas,
podem tornar os controles de segurana ineficazes
e/ou resultar no roubo dos dados do portador do
carto sem impacto perceptvel no processamento
normal.

11.5.bVerifique se o mecanismo est configurado para alertar
os funcionrios sobre modificaes no autorizadas de
arquivos crticos e para realizar comparaes de arquivos
crticos ao menos uma vez por semana.
11.5.1 Implemente um processo para
responder a qualquer alerta gerado pela
soluo de deteco de alteraes.
11.5.1 Questione os funcionrios para verificar se todos os
alertas so investigados e resolvidos.

para o teste e monitoramento da
segurana estejam documentados, em uso
envolvidas.
11.6 Analise a documentao e questione os funcionrios
para verificar se as polticas de segurana e procedimentos
operacionais para o teste e monitoramento da segurana
esto:
Documentados,
Em uso, e
operacionais para monitorar e testar a segurana
continuamente.

Manter uma poltica de segurana de informaes
Requisito 12: Mantenha uma poltica que aborde a segurana da informao para todas as equipes.
Uma poltica de segurana slida determina o tom da segurana para toda a empresa e informa aos funcionrios o que esperado deles. Todos
os funcionrios devem estar cientes da confidencialidade dos dados e de suas responsabilidades para proteg-los. Para as finalidades do
Requisito 12, "funcionrio" refere-se a funcionrios que trabalham em perodo integral e meio-perodo, funcionrios e equipes temporrias e
prestadores de servios e consultores que "residem" no endereo da entidade ou tm acesso ao ambiente de dados do portador do carto.
Requisitos do PCI DSS Procedimentos de teste Orientao
12.1 Defina, publique, mantenha e
dissemine uma poltica de segurana.
12.1Analise a poltica de segurana da informao e verifique
se a poltica foi publicada e disseminada a todos os
funcionrios relevantes (incluindo fornecedores e parceiros
comerciais).
A poltica de segurana de informaes de uma
empresa cria um guia para implementar as
medidas de segurana para proteger seus ativos
mais valiosos. Todos os funcionrios devem estar
cientes da confidencialidade dos dados e de suas
responsabilidades para proteg-los.
12.1.1 Revise a poltica de segurana
ao menos uma vez por ano e atualize a
poltica quando o ambiente for alterado.
12.1.1 Verifique se a poltica de segurana da informao
analisada pelo menos uma vez por ano e atualizada
conforme necessrio para refletir as alteraes nos objetivos
de negcios ou no ambiente de risco.
As ameaas de segurana e os mtodos de
proteo evoluem rapidamente. Sem atualizar a
poltica de segurana para refletir essas
alteraes, agora so abordadas novas medidas
de proteo para lutar contra essas ameaas.
12.2 Implemente um processo de
avaliao de risco que:
Seja realizado ao menos uma vez por
ano e quando houver modificaes
significativas no ambiente (por
exemplo, aquisio, fuso,
transferncia, etc.),
Identifique os recursos, ameaas e
vulnerabilidades crticos, e
Resulte em uma avaliao formal de
risco.
Os exemplos de metodologias de
avaliao de risco incluem, entre outros,
OCTAVE, ISO 27005 e NIST SP 800-30.
12.2.a Verifique se um processo anual de avaliao de risco
est documentado e se identifica ativos, ameaas e
vulnerabilidades e resulta em uma avaliao de risco formal.
Uma avaliao de riscos permite a uma
organizao identificar ameaas e
vulnerabilidades relacionadas que tm o potencial
de causar um impacto negativo em seus
negcios. Os recursos podem ento ser alocados
com eficcia para implementar controles que
reduzem a probabilidade e/ou o impacto potencial
da ameaa em questo.
Realizar avaliaes de riscos anuais e quando
houver alteraes significativas permite
organizao manter-se atualizada com as
mudanas organizacionais e ameaas,
tendncias e tecnologias em evoluo.
12.2.b Analise a documentao da avaliao de risco para
verificar se o processo de avaliao de risco realizada ao
menos uma vez por ano e quando houver alteraes
significativas no ambiente.

12.3 Desenvolva o uso de polticas de
tecnologias crticas e defina o uso
apropriado destas tecnologias.
Observao: Exemplos de tecnologias
crticas incluem, entre outros, tecnologias
de acesso remoto e sem fio, laptops,
tablets, mdia eletrnica removvel, uso de
e-mails e da internet.
Garanta que essas polticas de utilizao
exijam o seguinte:
12.3 Analise as polticas de uso das tecnologias crticas e
questione os funcionrios responsveis para verificar se as
seguintes polticas esto implementadas e so seguidas:
As polticas de uso por funcionrios podem proibir
o uso de determinados dispositivos e outras
tecnologias, se for essa a poltica da empresa, ou
fornecer orientao para os funcionrios quanto
ao uso e implementao corretos. Se polticas
de uso no estiverem vigentes, os funcionrios
podem usar as tecnologias na violao da poltica
da empresa, permitindo que indivduos mal-
intencionados consigam acesso a sistemas
crticos e dados do portador do carto.
12.3.1 Aprovao explcita por partes
autorizadas
12.3.1 Verifique se as polticas de utilizao incluem
processos para aprovao explcita das partes autorizadas
para usar as tecnologias.
Sem exigir aprovao adequada do
gerenciamento para implementao dessas
tecnologias, um funcionrio pode implementar
inocentemente uma soluo para uma
necessidade de negcios percebida, mas tambm
abrir um grande buraco que deixe os sistemas e
dados crticos vulnerveis a indivduos mal-
intencionados.
12.3.2 Autenticao para o uso da
tecnologia
12.3.2 Verifique se as polticas de utilizao incluem
processos para que todo o uso da tecnologia seja
autenticado com ID de usurio e senha ou outro item de
autenticao (por exemplo, token).
Se a tecnologia for implementada sem
autenticao adequada (IDs de usurio e senhas,
tokens, VPNs, etc.), indivduos mal-intencionados
podem facilmente usar essa tecnologia
desprotegida para acessar sistemas crticos e
12.3.3 Uma lista de todos esses
dispositivos e equipes com acesso
12.3.3 Verifique se as polticas de utilizao definem uma
lista de todos os dispositivos e equipes autorizadas a usar
os dispositivos.
Os indivduos mal-intencionados podem violar a
segurana fsica e colocar seus prprios
dispositivos na rede como uma backdoor. Os
funcionrios tambm podem se desviar dos
procedimentos e instalar dispositivos. Um
inventrio preciso, com rtulos adequados nos
dispositivos, permite uma rpida identificao das
instalaes no aprovadas.

12.3.4 Um mtodo para determinar
prontamente e precisamente o
proprietrio, informaes de contato e
propsito (por exemplo, etiqueta,
codificao, e/ou inventrio de
dispositivos)
12.3.4 Verifique se as polticas de utilizao definem um
mtodo para determinar prontamente e precisamente o
proprietrio, informaes de contato e propsito (por
exemplo, etiqueta, codificao, e/ou inventrio de
dispositivos).
Os indivduos mal-intencionados podem violar a
segurana fsica e colocar seus prprios
dispositivos na rede como uma backdoor. Os
funcionrios tambm podem se desviar dos
procedimentos e instalar dispositivos. Um
inventrio preciso, com rtulos adequados nos
dispositivos, permite uma rpida identificao das
instalaes no aprovadas. Pense em criar uma
conveno de nomes oficiais para dispositivos e
registre todos os dispositivos com os controles de
inventrio criados. Rtulos lgicos podem ser
empregados com informaes, como cdigos que
podem ser associados ao proprietrio, a
informaes de contato e sua finalidade.
12.3.5 Usos aceitveis da tecnologia 12.3.5 Verifique se as polticas de utilizao definem usos
aceitveis quanto tecnologia.
Ao definir o uso corporativo aceitvel e a
localizao dos dispositivos e da tecnologia
aprovados pela empresa, a empresa fica mais
capaz de gerenciar e controlar falhas nas
configuraes e nos controles operacionais, a fim
de garantir que no tenha sido aberta uma
backdoorpara um indivduo mal-intencionado
obter acesso a sistemas crticos e a dados do
portador do carto.
12.3.6 Locais de rede aceitveis quanto
s tecnologias
12.3.6 Verifique se as polticas de utilizao definem locais
de rede aceitveis quanto tecnologia.
12.3.7Lista dos produtos aprovados pela
empresa
12.3.7 Verifique se as polticas de utilizao incluem uma
lista de produtos aprovados pela empresa.
12.3.8 Desconexo automtica das
sesses quanto s tecnologias de
acesso remoto aps um perodo
especfico de inatividade
12.3.8 Verifique se as polticas de utilizao exigem a
desconexo automtica das sesses quanto s tecnologias
de acesso remoto aps um perodo especfico de
inatividade.
As tecnologias de acesso remoto so frequentes
"backdoors" a recursos crticos e a dados do
portador do carto. Ao desconectar as
tecnologias de acesso remoto quando no
estiverem em uso (por exemplo, aquelas usadas
para dar suporte aos sistemas pelo fornecedor de
POS ou por outros fornecedores), o acesso e os
riscos rede so minimizados.
12.3.8.b Analise as configuraes para as tecnologias de
acesso remoto para verificar se as sesses de acesso
remoto sero desconectadas automaticamente aps um
perodo determinado de inatividade.
12.3.9 Ativao de tecnologias de
acesso remoto para fornecedores e
parceiros de negcio somente quando
lhes for necessrio, com desativao
imediata aps o uso
12.3.9 Verifique se as polticas de utilizao exigem a
ativao de tecnologias de acesso remoto usadas pelos
fornecedores somente quando lhes for necessrio, com
desativao imediata aps o uso.

12.3.10 Para funcionrios que acessam
os dados do portador do carto por meio
de tecnologias de acesso remoto, proba
a cpia, a transferncia e o
armazenamento dos dados do portador
do carto em discos rgidos locais e
mdias eletrnicas removveis, exceto se
explicitamente autorizado para uma
necessidade comercial definida.
Onde houver uma necessidade
comercial autorizada, as polticas de
utilizao devem exigir que os dados
sejam protegidos de acordo com todos
os requisitos aplicveis do PCI DSS.
12.3.10.a Verifique se as polticas de utilizao probem a
cpia, a transferncia ou o armazenamento dos dados do
portador do carto em discos rgidos locais e mdias
eletrnicas removveis ao acessar esses dados por meio de
tecnologias de acesso remotas.
Para garantir que os funcionrios estejam cientes
de suas responsabilidades de no armazenar
nem copiar dados do portador do carto para o
computador pessoal local ou outras mdias, sua
empresa deve contar com uma poltica que proba
claramente essas atividades, exceto para os
funcionrios que foram expressamente
autorizados para isso. Armazenar ou copiar
dados do portador do carto em discos rgidos
locais ou outras mdias deve estar de acordo com
todos os requisitos aplicveis do PCI DSS.
12.3.10.b Para funcionrios com autorizao adequada,
verifique se o uso de polticas exige a proteo dos dados
do portador do carto de acordo com os requisitos do PCI
DSS.
12.4 Certifique-se de que a poltica e os
procedimentos de segurana definem
claramente as responsabilidades quanto
segurana da informao para todos os
funcionrios.
12.4.a Verifique se as polticas de segurana da informao
definem claramente as responsabilidades quanto
segurana da informao para todos os funcionrios.
Sem funes e responsabilidades claramente
definidas e atribudas, pode haver uma interao
inconsistente com o grupo de segurana, levando
a uma implementao no protegida de
tecnologias ou ao uso de tecnologias no
protegidas ou desatualizadas.
12.4.b Converse com alguns funcionrios responsveis para
verificar se eles compreendem as polticas de segurana.
12.5 Atribua a um indivduo ou a uma
equipe as seguintes responsabilidades de
gerenciamento da segurana da
informao:
12.5 Analise as polticas e procedimentos de segurana da
informao para verificar:
A atribuio formal da segurana da informao com
relao a um Diretor de segurana ou outro membro do
gerenciamento que tenha conhecimento sobre
segurana.
As seguintes responsabilidades da segurana da
informao so atribudas modo formal e especfico:
Cada pessoa ou equipe com responsabilidades
pela gesto da segurana da informao deve
estar claramente ciente das responsabilidades e
das tarefas relacionadas por meio da poltica
especfica. Sem essa responsabilidade, falhas
nos processos podem dar acesso a recursos
crticos ou dados do portador do carto.

12.5.1 Defina, documente e distribua
polticas e procedimentos de segurana.
12.5.1 Verifique se a responsabilidade de definir,
documentar e distribuir polticas e procedimentos de
segurana est formalmente atribuda.

12.5.2 Monitore e analise os alertas e as
informaes de segurana e distribua
para as equipes apropriadas.
12.5.2 Verifique se a responsabilidade pelo monitoramento e
anlise dos alertas de segurana e pela distribuio de
informaes s equipes de gerenciamento adequadas da
segurana da informao e das unidades de negcios foi
formalmente atribuda.
12.5.3 Defina, documente e distribua
procedimentos de resposta e escalao
de incidentes de segurana para
assegurar que todas as situaes sejam
abordadas de modo oportuno e
eficiente.
12.5.3 Verifique se a responsabilidade de definir,
documentar e distribuir procedimentos de resposta e
escalao de incidentes de segurana formalmente
atribuda.
12.5.4 Administre as contas dos
usurios, incluindo adies, excluses e
modificaes.
12.5.4 Verifique se a responsabilidade pela administrao
(adio, excluso e modificao) das contas dos usurios e
do gerenciamento da autenticao formalmente atribuda.
12.5.5 Monitore e controle todos os
acessos aos dados.
12.5.5 Verifique se a responsabilidade por monitorar e
controlar todo o acesso aos dados formalmente atribuda.
12.6Implemente um programa formal de
conscientizao da segurana para
conscientizar todos os funcionrios sobre
a importncia da segurana dos dados do
portador do carto.
12.6.a Revise o programa de conscientizao da segurana
para verificar se ele conscientiza os funcionrios sobre a
importncia da segurana dos dados do portador do carto.
Se os usurios no forem treinados sobre as
responsabilidades de segurana, as protees e
os processos que forem implementados podero
se tornar ineficazes por causa de erros do
funcionrio ou aes no intencionais.
12.6.b Analise os procedimentos e a documentao do
programa de conscientizao de segurana e realize o
seguinte:
12.6.1 Instrua os funcionrios quando
da contratao e pelo menos uma vez
por ano.
Observao: Os mtodos podem variar
dependendo da funo de cada
funcionrio e do nvel de acesso aos
12.6.1.a Verifique se o programa de conscientizao da
segurana fornece vrios mtodos para transmitir a
conscientizao e instruir os funcionrios (por exemplo,
cartazes, cartas, memorandos, treinamento com base na
Web, reunies e promoes).
Se o programa de conscientizao de segurana
no incluir sesses de atualizao anuais, os
principais processos e procedimentos de
segurana podero ser esquecidos ou ignorados,
resultando em exposio dos recursos crticos e
dos dados do portador do carto.
12.6.1.b Verifique se os funcionrios participam do
treinamento de conscientizao relacionados contratao
pelo menos uma vez por ano.
12.6.1.c Questione alguns funcionrios para verificar se eles
concluram o treinamento para se conscientizar da
importncia da segurana dos dados do portador do carto.

12.6.2 Solicite que os funcionrios
reconheam, pelo menos uma vez ao
ano, que leram e compreenderam a
poltica e os procedimentos de
segurana da empresa.
12.6.2 Verifique se o programa de conscientizao da
segurana requer que os funcionrios reconheam, por
escrito ou eletronicamente, pelo menos uma vez ao ano,
que leram e compreenderam a poltica de segurana da
informao da empresa.
Requerer um reconhecimento dos funcionrios,
por escrito ou eletronicamente, ajuda a garantir
que eles tenham lido e entendido as polticas e os
procedimentos de segurana e que eles tenham
se comprometido a obedecer a essas polticas.
12.7 Analise bem os potenciais
funcionrios antes de contratar a fim de
minimizar o risco de invases a partir de
fontes internas. (Exemplos de verificaes
da formao incluem o histrico do
emprego anterior, ficha criminal, histrico
de crdito e verificaes das referncias.)
Observao: Para os funcionrios como
caixas de loja, que tm acesso somente a
um nmero do carto por vez ao viabilizar
uma transao, esse requisito apenas
uma recomendao.
12.7 Questione o gerenciamento do departamento de
Recursos Humanos e verifique se as verificaes da formao
so realizadas (dentro das restries das leis locais) antes de
contratar funcionrios que tero acesso aos dados do
portador do carto ou ao ambiente desses dados.
Executar investigaes de histrico completas
antes de contratar funcionrios que se espera que
tenham acesso aos dados do portador do carto
reduz o risco do uso no autorizado de PANs e
outros dados do portador do carto por pessoas
com histricos questionveis ou criminais.
12.8 Mantenha e implemente polticas e
procedimentos para controlar os
prestadores de servios com quem os
dados do portador so compartilhados, ou
que possam afetar a segurana dos
dados, conforme segue:
12.8 Por meio de observao, revise as polticas e
procedimentos e a documentao de suporte, verifique se
esto implementados processos para controlar prestadores de
servios com quem os dados do portador do carto so
compartilhados, ou que podem afetar sua segurana (por
exemplo, reas de armazenamento de fitas de backup,
prestadores de servios gerenciados, como empresas de
hospedagem na Web ou prestadores de servios de
segurana, aqueles que recebem dados para fins de
determinao de fraude, etc.), conforme segue:
Se o comerciante ou o prestador de servio
compartilhar os dados do portador do carto com
um prestador de servio, devem ser aplicados
certos requisitos para garantir a proteo
contnua desses dados por tais prestadores de
servio.
12.8.1 Mantenha uma lista dos
prestadores de servios.
12.8.1 Verifique se uma lista dos prestadores de servios
mantida.
Rastrear todos os provedores de servio identifica
quando possveis riscos se estenderem para fora
da organizao.

12.8.2 Mantenha um acordo por escrito
que inclua um reconhecimento de que
os prestadores de servios so
responsveis pela segurana dos dados
do portador do carto que eles
possurem, ou que os armazenam,
processam ou transmitem em nome do
cliente, ou ao ponto de que eles possam
impactar a segurana do ambiente dos
dados do portador do carto do cliente.
Observao: As informaes exatas
contidas no reconhecimento dependero
do acordo entre as duas partes, dos
detalhes do servio a ser prestado e das
responsabilidades atribudas a cada parte.
O reconhecimento no precisa ser
exatamente igual ao fornecido neste
requisito.
12.8.2 Observe os acordos por escrito e confirme se eles
incluem um reconhecimento de que os prestadores de
servios so responsveis pela segurana dos dados do
portador do carto que eles possurem, ou que os
armazenam, processam ou transmitem em nome do cliente,
ou ao ponto de que eles possam impactar a segurana do
ambiente dos dados do portador do carto do cliente.
O reconhecimento dos prestadores de servio
evidencia o seu compromisso em manter a
segurana adequada dos dados do portador do
carto que so obtidos dos clientes.
J untamente com o Requisito 12.9, este requisito
para acordos escritos entre as organizaes e
prestadores de servios tem o objetivo de
promover um nvel consistente de entendimento
entre as partes sobre suas responsabilidades
aplicveis do PCI DSS. Por exemplo, o acordo
pode incluir que os requisitos aplicveis do PCI
DSS sejam mantidos como parte do servio
prestado.

12.8.3 Certifique-se de que haja um
processo definido para a contratao
dos prestadores de servios, incluindo
uma diligncia devida adequada antes
da contratao.
12.8.3 Verifique se as polticas e procedimentos esto
documentados e implementados, incluindo a diligncia
devida adequada antes da contratao de qualquer
prestador de servios.
O processo garante que qualquer envolvimento
de um prestador de servio seja totalmente
vetado internamente pela organizao, que deve
incluir uma anlise de risco antes de estabelecer
um relacionamento formal com o prestador de
servios.
Os processos de diligncia devida e metas
especficos variam para cada organizao.
Exemplos de consideraes podem incluir as
prticas de relatrios do fornecedor,
procedimentos de aviso de violao e resposta a
incidentes, detalhes de como as
responsabilidades do PCI DSS so atribudas
entre cada parte, como o fornecedor valida sua
conformidade com o PCI DSS e qual evidncia
eles iro fornecer, etc.

12.8.4 Mantenha um programa para
monitorar anualmente o status de
conformidade com o PCI DSS dos
prestadores de servios.
12.8.4 Verifique se a entidade mantm um programa para
monitorar o status de conformidade com o PCI DSS dos
prestadores de servios pelo menos uma vez ao ano.
Conhecer o status de conformidade do prestador
de servio com o PCI DSS fornece uma garantia
a mais de que eles esto de acordo com os
mesmos requisitos aos quais a organizao est
sujeita. Se o provedor oferecer diversos servios,
este requisito se aplicar apenas aos servios
realmente prestados ao cliente e os servios que
estiverem dentro do escopo da avaliao de PCI
DSS do cliente.
A informao especfica que uma entidade
mantm depender do acordo particular com
seus fornecedores, o tipo de servio, etc. O
objetivo que a entidade avaliada entenda quais
requisitos do PCI DSS seus fornecedores
concordaram em atender.
12.8.5 Mantenha informaes sobre
quais requisitos do PCI DSS so
administrados por cada prestador de
servios e quais so administrados pela
entidade.
12.8.5 Verifique se a entidade mantm informaes sobre
quais requisitos do PCI DSS so administrados por cada
prestador de servios e quais so administrados pela
entidade.

12.9 Requisito adicional para
prestadores de servios: Os
prestadores de servios reconhecem por
escrito aos clientes que eles so
responsveis pela segurana dos dados
do portador do carto que eles possurem,
ou que os armazenam, processam ou
transmitem em nome do cliente, ou ao
ponto de que eles possam impactar a
segurana do ambiente dos dados do
portador do carto do cliente.
Observao: O requisito considerado
uma das melhores prticas at 30 de
junho de 2015 quando passar a ser um
requisito.
Observao: As informaes exatas
contidas no reconhecimento dependero
do acordo entre as duas partes, dos
detalhes do servio a ser prestado e das
responsabilidades atribudas a cada parte.
O reconhecimento no precisa ser
exatamente igual ao fornecido neste
requisito.
12.9 Procedimento de teste adicional para prestadores de
servios: Revise as polticas e procedimentos do prestador
de servios e observe os modelos de acordos escritos para
confirmar se ele reconhece por escrito aos clientes que
manter todos os requisitos aplicveis do PCI DSS ao limite
em que ele procede, tem acesso ou armazena, processa ou
transmite os dados do portador do carto do cliente ou dados
de autenticao confidenciais, ou que administra o ambiente
de dados do portador do carto em nome de um cliente.
Este requisito se aplica quando a entidade que
est sendo avaliada um prestador de servios.
J untamente com o Requisito 12.8.2, este requisito
tem o objetivo de promover um nvel consistente
de entendimento entre os prestadores de servios
e seus clientes sobre suas responsabilidades
aplicveis do PCI DSS. O reconhecimento dos
prestadores de servio evidencia o seu
compromisso em manter a segurana adequada
dos dados do portador do carto que so obtidos
dos clientes.
O mtodo pelo qual o prestador de servios
fornece o reconhecimento por escrito deve ser
acordado entre o fornecedor e seus clientes.
12.10 Implemente um plano de resposta a
incidentes. Prepare-se para reagir
imediatamente a uma falha no sistema.
12.10 Analise o plano de resposta a incidentes e os
procedimentos relatados para verificar se a entidade est
preparada para reagir imediatamente a uma violao no
sistema realizando o que segue:
Sem um plano de resposta a incidentes de
segurana completo que seja adequadamente
disseminado, lido e entendido pelas partes
responsveis, a confuso e a falta de uma
resposta unificada podem criar mais tempo ocioso
para a empresa, exposio pblica desnecessria
e novas responsabilidades legais.

12.10.1 Crie o plano de resposta a
incidentes para ser implementado no
caso de violaes do sistema.
Certifique-se de que o plano aborda o
seguinte, pelo menos:
Funes, responsabilidades e
estratgias de comunicao e
contato no caso de um
comprometimento, incluindo a
notificao s bandeiras de
pagamento, pelo menos
Procedimentos de resposta
especficos a incidentes
Procedimentos de recuperao e
continuidade dos negcios
Processos de backup dos dados
Anlise dos requisitos legais
visando ao relato dos
comprometimentos
Abrangncia e resposta de todos os
componentes crticos do sistema
Referncia ou incluso de
procedimentos de resposta a
incidentes por parte das bandeiras.
12.10.1.a Verifique se o plano de resposta a incidentes
inclui:
Funes, responsabilidades e estratgias de
comunicao no caso de um comprometimento,
incluindo a notificao s bandeiras de pagamento, pelo
menos
Procedimentos de resposta especficos a incidentes
Procedimentos de recuperao e continuidade dos
negcios
Processos de backup dos dados
Anlise dos requisitos legais referentes ao relato dos
comprometimentos (por exemplo, Lei 1386 da
Califrnia, que exige a notificao dos clientes afetados
no caso de um comprometimento real ou suspeito para
qualquer negcio que seja realizado com moradores da
Califrnia em seu banco de dados)
Abrangncia e resposta de todos os componentes
crticos do sistema
Referncia ou incluso de procedimentos de resposta a
incidentes por parte das bandeiras.
O plano de resposta a incidentes deve ser
completo e conter todos os elementos-chave para
permitir que sua empresa reaja com eficincia no
caso de uma violao que possa causar impacto
nos dados do portador do carto.
12.10.1.b Questione os funcionrios e revise a
documentao a partir de incidentes ou alertas relatados
previamente para verificar se o plano e os procedimentos de
resposta ao incidente documentado foram seguidos.
12.10.2 Teste o plano pelo menos uma
vez ao ano.
12.10.2 Verifique se o plano testado pelo menos uma vez
ao ano.
Sem testes adequados, etapas essenciais podem
ser perdidas, o que poderia aumentar a exposio
durante um incidente.
12.10.3 Designe equipes especficas
para estarem disponveis em tempo
integral para responder aos alertas.
12.10.3 Verifique, por meio da observao, anlise das
polticas e entrevistas com funcionrios responsveis se a
equipe designada est disponvel para cobertura de
monitoramento e resposta a incidentes em tempo integral
para qualquer evidncia de atividade no autorizada,
deteco de pontos de acesso sem fio no autorizados,
alertas de IDS crticos e/ou relatrios de sistemas crticos
no autorizados ou alteraes nos arquivos de contedo.
Sem uma equipe de reao a incidentes treinada
e prontamente disponvel, podem ocorrer danos
extensos rede e dados e sistemas crticos
podem ficar poludospelo manuseio inadequado
dos sistemas almejados. Isso pode evitar o
sucesso de uma investigao ps-incidente.

12.10.4 Fornea treinamento adequado
equipe que responsvel pela
resposta s falhas do sistema.
12.10.4 Verifique, por meio de observao, anlises das
polticas e entrevistas com os funcionrios responsveis se
a equipe com responsabilidades de resposta a violaes de
segurana so treinadas periodicamente.
12.10.5 Inclua alertas a partir dos
sistemas de monitoramento de
segurana, incluindo, entre outros,
deteco e preveno contra invases,
firewalls e sistemas de monitoramento
da integridade dos arquivos.
12.10.5 Verifique, por meio da observao e da anlise dos
processos, se o monitoramento e a resposta aos alertas a
partir dos sistemas de monitoramento de segurana,
incluindo deteco dos pontos de acesso sem fio no
autorizados, so abordados no plano de resposta a
incidentes.
Esses sistemas de monitoramento so feitos para
se concentrar em possveis riscos aos dados, so
essenciais para se tomar uma ao rpida para
evitar uma violao e devem estar includos nos
processos de resposta a incidentes.
12.10.6 Desenvolva um processo para
modificar e aprimorar o plano de
resposta a incidentes, de acordo com as
lies aprendidas e para incorporar os
desenvolvimentos do setor.
12.10.6 Verifique, por meio da observao, da anlise das
polticas e entrevistas com os funcionrios responsveis se
h um processo para modificar e aprimorar o plano de
resposta a incidentes, de acordo com as lies aprendidas e
para incorporar os desenvolvimentos do setor.
Incorporar as lies aprendidasno plano de
reao a incidentes depois de um incidente ajuda
a manter o plano atualizado e capaz de reagir s
ameaas que surgirem e s tendncias de
segurana.

Apndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem
compartilhada
Requisito A.1: Os provedores de hospedagem compartilhada devem proteger o ambiente de dados do portador do carto
Conforme mencionado no Requisito 12.8 e 12.9, todos os prestadores de servios com acesso aos dados do portador do carto (incluindo os
provedores de hospedagem compartilhada) devem seguir o PCI DSS. Alm disso, o Requisito 2.6 afirma que os provedores de hospedagem
compartilhada devem proteger o ambiente hospedado e os dados de cada entidade. Portanto, os provedores de hospedagem compartilhada
tambm devem estar em conformidade com os requisitos nesse Apndice.

Requisitos Procedimentos de teste Orientao
A.1 Proteja o ambiente hospedado e os
dados de cada entidade (seja
comerciante, prestador de servios ou
outra entidade), de acordo com os itens
A.1.1 a A.1.4:
O provedor de hospedagem deve
cumprir esses requisitos e todas as
outras sees relevantes do PCI DSS.
Observao: Mesmo que o provedor de
hospedagem cumpra esses requisitos, a
conformidade da entidade que usa o
provedor de hospedagem no est
assegurada. Cada entidade deve estar
em conformidade com o PCI DSS e
validar a conformidade, conforme
aplicvel.
A.1Especificamente para uma avaliao do PCI DSS de um
provedor de hospedagem compartilhada, para verificar se os
provedores de hospedagem compartilhada protegem o ambiente
hospedado e os dados das entidades (comerciantes e prestadores
de servios), selecione um exemplo de servidores (Microsoft
Windows e Unix/Linux) dentre vrios exemplos representativos de
comerciantes e prestadores de servios, e desempenhe o que est
descrito nos itens A.1.1 a A.1.4 abaixo:
O Apndice A do PCI DSS destinado a
provedores de hospedagem compartilhada
que desejam fornecer aos clientes do
comerciante e/ou prestador de servio um
ambiente de hospedagem em conformidade
com o PCI DSS.

A.1.1 Certifique-se de que cada
entidade executa somente os
processos que tm acesso aos dados
do portador do carto daquela
entidade.
A.1.1 Se um provedor de hospedagem compartilhada permitir que
as entidades (por exemplo, comerciantes ou prestadores de
servios) executem seus prprios aplicativos, verifique se os
processos desses aplicativos so executados usando o ID
exclusivo da entidade. Por exemplo:
Nenhuma entidade no sistema pode usar um ID de usurio do
servidor Web compartilhado.
Todos os scripts CGI usados por uma entidade devem ser
criados e executados como o ID do usurio exclusivo da
entidade.
Se um comerciante ou prestador de
servio puder executar seus prprios
aplicativos no servidor compartilhado, eles
devem ser executados com o ID de
usurio do comerciante ou prestador de
servio e no como um usurio
privilegiado.
A.1.2 Restrinja o acesso e os
privilgios de cada entidade somente
ao prprio ambiente de dados do
portador do carto.
A.1.2.a Verifique se o ID do usurio de qualquer processo de
aplicativos no um usurio privilegiado (raiz/admin).
Para garantir que os acessos e os
privilgios estejam restritos, de forma que
cada comerciante ou prestador de servio
s tenha acesso ao prprio ambiente dos
dados, considere o seguinte:
1. Privilgios do ID do usurio do
servidor Web do prestador de servios
ou do comerciante;
2. Permisses concedidas para ler,
escrever e executar arquivos;
3. Permisses concedidas para escrever
em binrios do sistema;
4. Permisses concedidas para arquivos
de log dos comerciantes e prestadores
de servios; e
5. Controles para garantir que um
comerciante ou prestador de servios
no possa monopolizar recursos do
sistema.
A.1.2.b Verifique se cada entidade (comerciante, prestador de
servios) leu, gravou ou executou as permisses somente
referentes aos arquivos e diretrios que possui ou para os arquivos
de sistema necessrios (restringidos por meio das permisses do
sistema de arquivo, listas de controle de acesso, chroot, jailshell,
etc.).
Importante: Os arquivos de uma entidade no podem ser
compartilhados em grupo.
A.1.2.c Verifique se os usurios da entidade no tm acesso de
gravao aos binrios compartilhados do sistema.
A.1.2.d Verifique se a visualizao das entradas de log restrita
entidade detentora.
A.1.2.e Para assegurar que cada entidade no possa monopolizar
os recursos do servidor para explorar as vulnerabilidades (por
exemplo, condies de erro, acelerao e reinicializao,
resultando, por exemplo, em sobrecargas de buffer), verifique se
as restries foram implementadas para a utilizao destes
recursos do sistema:
Espao em disco
Largura de banda
Memria
CPU

A.1.3 Certifique-se de que os registros
e as trilhas de auditoria esto ativados
e so exclusivos para o ambiente de
dados do portador do carto de cada
entidade, alm de estarem em
conformidade com o Requisito 10 do
PCI DSS.
A.1.3 Verifique se o provedor de hospedagem compartilhada ativou
os registros conforme segue, para o ambiente de cada comerciante
e prestador de servios:
Os registros so ativados para os aplicativos de terceiros
comuns.
Como padro, os registros esto ativados.
Os registros esto disponveis para anlise pela entidade
detentora.
As localizaes dos registros so informadas com clareza
entidade detentora.
Os logs devem estar disponveis em um
ambiente de hospedagem compartilhado,
de forma que os comerciantes e
prestadores de servio tenham acesso e
consigam analisar os logs especficos ao
ambiente dos dados do portador do
carto.
A.1.4 Permita que os processos
providenciem uma investigao
forense oportuna no caso de um
comprometimento em qualquer
comerciante ou prestador de servios
hospedado.
A.1.4 Verifique se o provedor de hospedagem compartilhada
definiu polticas que fornecem uma investigao forense oportuna
dos servidores relacionados no caso de um comprometimento.
Os provedores de hospedagem
compartilhada devem ter processos para
fornecer uma resposta rpida e fcil no
caso de uma investigao forense ser
necessria para um comprometimento,
at o nvel adequado de detalhes, de
forma que os detalhes individuais do
comerciante ou do prestador de servio
estejam disponveis.

Padro de segurana de dados da Indstria de cartes de pagamento (PCI), v3.0 Novembro de 2013
2006-2013 PCI Security Standards Council, LLC. Todos os direitos reservados. Pgina 125
Apndice B: Controles de compensao
Os controles de compensao podem ser considerados na maioria dos requisitos do PCI DSS quando
uma entidade no for capaz de atender a um requisito de forma explcita, conforme informado, devido a
restries de negcios documentadas ou tcnicas legtimas, mas minimizou o risco associado ao
requisito de modo suficiente por meio da implementao de outros controles, incluindo os de
compensao.
Os controles de compensao devem atender aos seguintes critrios:
1. Atender a inteno e o rigor do requisito original do PCI DSS.
2. Fornea um nvel semelhante de defesa ao requisito original do PCI DSS, como o controle de
compensao que contrabalana o risco de modo suficiente para o qual o requisito original do PCI
DSS tenha sido criado para fornecer uma defesa. (Consulte a seo Navegando no PCI DSS para
obter informaes sobre a inteno de cada requisito do PCI DSS.)
3. Esteja "acima e alm" dos outros requisitos do PCI DSS. (Simplesmente estar em conformidade com
outros requisitos do PCI DSS no um controle de compensao.)
Ao utilizar o critrio de avaliao "acima e alm" para controles de compensao, considere o
seguinte:
Observao: Os itens nas alternativas a) a c) abaixo so apenas exemplos. Todos os controles de
compensao devem ser analisados e validados quanto suficincia pelo responsvel pela avaliao
que realiza a anlise do PCI DSS. A efetividade de um controle de compensao depende das
especificidades do ambiente no qual o controle est implementado, dos controles de segurana ao redor
e da configurao do controle. As empresas devem estar cientes de que um determinado controle de
compensao no ser efetivo em todos os ambientes.
a) Os requisitos existentes do PCI DSS NO PODERO ser considerados como controles de
compensao se j tiverem sido exigidos para o item sob anlise. Por exemplo, as senhas para
o acesso administrativo realizado que no utiliza console devem ser enviadas criptografadas
para minimizar o risco de interceptao de senhas administrativas em texto simples. As
entidades no podem usar outros requisitos de senha do PCI DSS (bloqueio de invaso, senhas
complexas, etc.) para compensar a falta de senhas criptografadas, uma vez que os outros
requisitos de senha no diminuem o risco de interceptao de senhas de texto simples. Alm
disso, os outros controles de senha j so requisitos do PCI DSS referente ao item sob anlise
(contas).
b) Os requisitos existentes do PCI DSS PODEM ser considerados como controles de compensao
se forem exigidos para outra rea, mas no para o item sob anlise. Por exemplo: uma
autenticao com dois fatores um requisito do PCI DSS para o acesso remoto. A autenticao
com dois fatores a partir da rede interna tambm pode ser considerada um controle de
compensao para o acesso administrativo que no utiliza console quando no houver suporte
para a transmisso de senhas criptografadas. A autenticao com dois fatores pode ser um
controle de compensao aceitvel se: (1) atender ao objetivo do requisito original ao abordar o
risco de interceptao de senhas administrativas em texto simples; e (2) for configurada de modo
adequado e em um ambiente seguro.
c) Os requisitos existentes do PCI DSS podem ser combinados com novos controles para se
tornarem um controle de compensao. Por exemplo, se uma empresa no for capaz de tornar
os dados do portador do carto ilegveis de acordo com o Requisito 3.4 (por exemplo, por meio
da criptografia), um controle de compensao poderia consistir de um dispositivo ou uma
combinao de dispositivos, aplicativos e controles que abordam todos os itens a seguir: (1)
segmentao da rede interna; (2) filtragem do endereos IP ou endereo MAC; e (3)
autenticao com dois fatores dentro da rede interna.

Padro de segurana de dados da Indstria de cartes de pagamento (PCI), v3.0 Novembro de 2013
2006-2013 PCI Security Standards Council, LLC. Todos os direitos reservados. Pgina 126
4. Ser proporcional ao risco adicional imposto pelo no cumprimento do requisito do PCI DSS
O responsvel pela avaliao deve analisar os controles de compensao por completo durante cada
avaliao anual do PCI DSS para validar se cada controle de compensao aborda adequadamente o
risco para o qual o requisito do PCI DSS original foi elaborado, de acordo com os itens 1 a 4 acima. Para
manter a conformidade, os processos e controles devem estar implementados para assegurar que os
controles de compensao permaneam efetivos aps a concluso da avaliao.

Apndice C: Planilha dos controles de compensao
Use esta planilha para definir os controles de compensao para qualquer requisito no qual os controles
de compensao so usados para atender a um requisito do PCI DSS. Os controles de compensao
tambm devem ser documentados no Relatrio sobre Conformidade na seo do requisito do PCI DSS
correspondente.
Observao: Somente as empresas que realizaram uma anlise dos riscos e tm restries de negcios
documentadas ou tecnolgicas legtimas podem considerar o uso dos controles de compensao para
atingir a conformidade.

Nmero e definio do requisito:

Informaes necessri as Expli cao
1. Restri es Liste as restries que impossibilitam a
conformidade com o requisito original.

2. Objetivo Defina o objetivo do controle original;
identifique o objetivo atendido pelo
controle de compensao.

3. Risco identificado Identifique qualquer risco adicional
imposto pela ausncia do controle
original.

4. Definio dos
controles de
compensao
Defina os controles de compensao e
explique como eles abordam os
objetivos do controle original e o
aumento dos riscos, caso haja algum.

5. Validao dos
controles de
compensao
Defina como os controles de
compensao foram validados e
testados.

6. Manuteno Defina o processo e os controles
implementados para manter os
controles de compensao.

Planilha dos controles de compensao Exemplo completo
Use esta planilha para definir os controles de compensao para qualquer requisito indicado como
implantado via controles de compensao.
Nmero do requisito: 8.1.1 Todos os usurios so identificados com um ID de usurio exclusivo
antes de permitir que eles acessem os componentes do sistema ou os dados do portador do carto?
Informaes necessri as Expli cao
1. Restri es Liste as restries que
impossibilitam a
conformidade com o
requisito original.
A empresa XYZ utiliza Servidores Unix
independentes sem LDAP. Sendo assim,
cada um deles requer um logon "raiz". A
empresa XYZ no pode gerenciar o logon
"raiz" nem possvel registrar todas as
atividades "raiz" por usurio.
2. Objetivo Defina o objetivo do controle
original; identifique o
objetivo atendido pelo
controle de compensao.
O objetivo de exigir logons exclusivos duplo.
Primeiro, no considerado aceitvel, da
perspectiva de segurana, compartilhar
credenciais de logon. Segundo, ter logons
compartilhados impossibilita afirmar em
definitivo quem responsvel por uma
determinada ao.
3. Risco identificado Identifique qualquer risco
adicional imposto pela
ausncia do controle
original.
O risco adicional ocorre no sistema de
controle de acesso ao no assegurar que
todos os usurios tenham um ID exclusivo e
possam ser monitorados.
4. Definio dos
controles de
compensao
Defina os controles de
compensao e explique
como eles abordam os
objetivos do controle original
e o aumento dos riscos,
caso haja algum.
A empresa XYZ solicitar que todos os
usurios efetuem logon nos servidores a partir
dos seus desktops usando o comando SU
(usurio substituto). Isso permite que um
usurio acesse a conta "raiz" e desempenhe
aes na conta "raiz", mas possa efetuar
logon no diretrio de log do SU. Dessa forma,
cada ao do usurio pode ser rastreada pela
conta SU e a senha "raiz" no
compartilhada com os usurios.
5. Validao dos
controles de
compensao
Defina como os controles de
compensao foram
validados e testados.
A empresa XYZ demonstra ao responsvel
pela avaliao que o comando SU est sendo
executado em todas as atividades e que as
pessoas usando o comando efetuaram logon
para identificar que se o indivduo est
desempenhando aes com privilgios raiz.
6. Manuteno Defina o processo e os
controles implementados
para manter os controles de
compensao.
A empresa XYZ documenta os processos e
procedimentos para assegurar que as
configuraes do SU no sejam modificadas,
alteradas ou removidas para permitir que os
usurios individuais executem comandos raiz
sem serem monitorados, identificados e
registrados individualmente.

Apndice D: Segmentao e amostragem de reas de negcios/componentes do
sistema

PCI DSS V3-Signed

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PCI DSS V3-Signed

Загружено:

Авторское право:

Доступные форматы

Indstria de cartes de pagamento (PCI)

Padro de Segurana de Dados

Вам также может понравиться