Setor de cartões de pagamento (PCI) Padrão de segurança de dados de aplicativos de pagamento (PA-DSS)

(1)

Setor de cartões de pagamento (PCI)

Padrão de segurança de dados

de aplicativos de pagamento (PA-DSS)

Guia do programa

Versão 1.2

(2)

Guia do Programa PCI PA-DSS v. 1.2 Outubro de 2008

Alterações no documento

Data Versão Descrição

1 de outubro de

2008 1.2

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

(3)

Índice

Alterações no documento ... 1

Introdução... 3

Publicações relacionadas ... 3

Atualizações nos documentos e requisitos de segurança ... 3

Terminologia ... 3

Sobre o PCI ... 4

Visão geral e iniciativa de alinhamento do PA-DSS... 4

Funções e responsabilidades ... 4

Considerações do fornecedor – Preparação para a revisão ... 8

A quais aplicativos o PA-DSS se aplica? ... 8

Antes da revisão ... 8

Documentação e materiais necessários... 9

Programações da revisão do PA-DSS ... 9

Assessores de segurança qualificados do aplicativo de pagamento ... 10

Serviços do PA-DSS relacionados que podem ser oferecidos pelos PA-QSAs ... 10

Suporte técnico durante os testes ... 10

Acordo de liberação e entrega do relatório ... 10

Taxas ... 11

Visão geral dos processos do PA-DSS ... 12

Figura 1: Processo de aceitação do relatório do PA-DSS ... 13

Figura 2: Alterações do PA-DSS nos aplicativos listados ... 14

Figura 3: Grandfathering e transição dos aplicativos PABP à lista PA-DSS ... 15

Figura 4: Revalidação anual e renovação de aplicativos expirados do PA-DSS... 16

Figura 5: Programas do PA-QSA QA para revisões de relatórios ... 17

Visão geral do processo de aceitação do relatório do PA-DSS... 18

Alterações aos aplicativos de pagamento listados... 19

Renovação de aplicativos expirados ... 21

Transição e grandfathering de aplicativos de pagamento validados pelo PABP ... 22

Programa de controle da qualidade... 24

Processos de relatórios do PA-DSS ... 26

Notificação após uma quebra na segurança ou comprometimento ... 27

Termos e condições legais ... 29

Anexo A: Elementos para carta de aceitação e lista de aplicativos de pagamento validados pelo PA-DSS... 30

Anexo B: Identificação de criações de aplicativo de pagamento certificados ... 33

(4)

Introdução

Publicações relacionadas

O documento mencionado a seguir serve como base para as análises do Aplicativo de pagamento:  Requisitos do padrão de segurança de dados de

aplicativos de pagamento do setor de cartões de pagamento (PCI) – Requisitos e procedimentos de avaliação de segurança

 Padrão de segurança de dados de aplicativos de

pagamento do setor de cartões de pagamento (PCI) – Procedimentos da transição

Os documentos adicionais descritos a seguir são utilizados em conjunto com os mencionados anteriormente:

 Requisitos do padrão de segurança de dados do setor de

cartões de pagamento (PCI) – Requisitos e procedimentos de avaliação de segurança

 Glossário de termos, abreviações e acrônimos do Padrão

de segurança de dados do Setor de cartões de pagamento (PCI) e do Padrão de segurança de dados de aplicativos de pagamento

 Requisitos de validação do QSA do padrão de segurança

de dados do setor de cartões de pagamento (PCI)



Requisitos de validação do QSA do padrão de segurança de dados do setor de cartões de pagamento (PCI) – Suplemento para assessores de segurança qualificados do aplicativo de pagamento (PA-QSAs)

Observação:

Os Requisitos do PCI DSS e

Procedimentos de Avaliação de Segurança listam os requisitos

técnicos específicos e fornecem os procedimentos de avaliação e os modelos utilizados para validar a conformidade do aplicativo de pagamento e documentar a revisão. Os dois documentos Requisitos de validação do QSA definem os requisitos que devem ser atendidos por um PA-QSA para realizar as análises.

Todos os documentos estão disponíveis em meio eletrônico no site

www.pcisecuritystandards.org.

Atualizações nos documentos e requisitos de segurança

A segurança é uma batalha sem fim contra possíveis transgressores. Como resultado, é necessário revisar, atualizar e melhorar regularmente os requisitos de segurança utilizados para avaliar os aplicativos de pagamento. Como tal, o PCI SSC irá empenhar-se para atualizar os requisitos de segurança do aplicativo de pagamento a cada 24 meses.

O PCI SSC reserve-se o direito de alterar, corrigir ou remover requisitos de segurança a qualquer momento. Se tal alteração for necessária, o PCI SSC esforçar-se-á para trabalhar juntamente com a unidade do PCI SSC de Organizações Participantes e fornecedores de software para ajudar a reduzir o impacto de qualquer alteração.

Terminologia

Em todo o conteúdo deste documento:

 “PCI SSC” refere-se ao PCI Security Standards Council, LLC.

 “PABP” representa o antigo programa da Visa de Melhores Práticas do Aplicativo de Pagamento, no qual o Padrão de Segurança de Dados de Aplicativos de Pagamento (“PA-DSS”) foi baseado.  “Bandeira” referem-se às empresas de cartões de pagamento que são membros do PCI SSC,

atualmente American Express, Discover, JCB, MasterCard e Visa.

 “Aplicativos de pagamento” referem-se amplamente a aplicativos de pagamento que armazenam, processam ou transmitem dados de portador de cartão como parte da autorização ou acordo, em que esses aplicativos de pagamento são vendidos, distribuídos ou licenciados a terceiros.

(5)

Sobre o PCI

O PCI SSC reflete um desejo entre os componentes do Setor de cartões de pagamento (PCI) em todos os níveis para alinhar e padronizar requisitos de segurança, procedimentos de avaliação de segurança e processos para reconhecimento de aplicativos de pagamento validados por um PA-QSA. O PA-DSS e os padrões do PCI SSC relacionados definem uma estrutura de avaliação de segurança comum que é reconhecida por todas as bandeiras.

Todos os interessados na cadeia de valores de pagamentos beneficiam-se dos requisitos alinhados:  Os clientes tiram benefício de uma seleção mais ampla de aplicativos de pagamento seguros.  Os clientes têm a certeza de que estarão utilizando produtos que atendem ao nível necessário

de validação.

 Os fornecedores somente precisarão concluir uma única revisão do aplicativo de pagamento que será reconhecida por todas as bandeiras.

Para obter mais informações sobre o PCI SSC, acesse o site do PCI SSC no endereço www.pcisecuritystandards.org (o “site”).

Visão geral e iniciativa de alinhamento do PA-DSS

Este Guia do programa do PA-DSS do setor de cartões de pagamento reflete um alinhamento de todos os requisitos das bandeiras a um conjunto padronizado de:

 Procedimentos de avaliação e requisitos de segurança do aplicativo de pagamento

 Processos para reconhecimento dos aplicativos de pagamento validados pelos PA-QSAs

Observação:

Os relatórios do PA-DSS são revisados e

reconhecidos diretamente pelo PCI SSC.

 Processos para aplicativos de pagamento validados pelo PABP para transição à lista do SSC  Processos de controle de qualidade para PA-QSAs

A conformidade tradicional do PCI DSS pode não se aplicar diretamente aos fornecedores de aplicativos de pagamento, visto que a maioria não armazena, processa ou transmite dados do portador do cartão. No entanto, visto que esses aplicativos de pagamento são usados pelo cliente para armazenar,

processar e transmitir dados de portador de cartão, e os clientes precisam estar em conformidade com o PCI DSS, os aplicativos devem facilitar e não impedir a conformidade com o PCI DSS do cliente. Alguns exemplos de como os aplicativos de pagamento podem impedir a conformidade do PCI DSS incluem:

1. Dados de tarja magnética armazenados na rede do cliente após a autorização.

2. Aplicativos que exigem que os clientes desabilitem outros recursos necessários pelo PCI DSS, como software antivírus ou firewalls, para que o aplicativo de pagamento funcione corretamente. 3. Uso por parte do fornecedor de métodos não seguros para conectar-se ao aplicativo para

oferecer suporte ao cliente.

Os aplicativos de pagamento seguros, quando implementados em um ambiente compatível com

PCI-DSS, minimizarão as possibilidades de quebras na segurança, levando ao comprometimento de todos os

dados da tarja magnética, códigos e valores de validação do cartão (CAV2, CID, CVC2 e CVV2), PINs e bloqueios de PIN e a fraudes destruidoras resultantes dessas quebras.

Funções e responsabilidades

Existem vários interessados na comunidade do aplicativo de pagamento. Alguns desses interessados possuem uma participação mais direta no processo de avaliação do PA-DSS – fornecedores, PA-QSAs e

(6)

PCI SSC. Os outros que não estão diretamente envolvidos no processo de avaliação devem estar cientes do processo geral para facilitar suas decisões de negócios associadas.

A seguir encontram-se as definições das funções e das responsabilidades dos participantes da comunidade do aplicativo de pagamento. Esses interessados envolvidos no processo de avaliação possuem as responsabilidades relacionadas listadas a seguir.

Empresas de pagamento

A American Express, Discover Financial Services, JCB International, MasterCard Worldwide e Visa Inc. são as empresas de pagamento que fundaram o PCI SSC. Essas empresas são responsáveis pelo desenvolvimento e utilização de quaisquer programas relacionados à conformidade do PA-DSS, incluindo sem limitações o seguinte:

 Quaisquer requisitos, mandatos ou datas para uso dos aplicativos de pagamento em conformidade com o PA-DSS.

 Quaisquer multas ou penalidades relacionadas ao uso de aplicativos de pagamento não conformes.

As bandeiras podem definir a conformidade dos programas, mandatos, datas, etc. usando o PA-DSS e os aplicativos de pagamento validados listados pelo PCI SSC. Por meio desses programas de

conformidade, as bandeiras promovem o uso dos aplicativos de pagamento validados relacionados.

Conselho de padrões de segurança do setor de cartões de pagamento (PCI SSC)

O PCI SSC é o organismo de normas que mantém os padrões do setor de cartões de pagamento, incluindo o PCI DSS e o PA-DSS. Em relação ao PA-DSS, o PCI SSC:

 É um repositório centralizado para Relatórios de validação (ROVs) do PA-DSS.

 Realiza revisões de Controle de qualidade (QA) dos ROVs do PA-DSS para confirmar a consistência e a qualidade do relatório.

 Lista os aplicativos de pagamento validados do PA-DSS no site. Observe que esta lista estará

disponível no site somente após outubro de 2008.

 Qualifica e treina os PA-QSAs para realizar revisões do PA-DSS.

 Mantém e atualiza os padrões do PA-DSS e a documentação relacionada de acordo com o processo de gerenciamento do ciclo de vida dos padrões.

Observe que o PCI SSC não aprova relatório de uma perspectiva de validação. A função do PA-QSA é documentar a conformidade do aplicativo de pagamento ao PA-DSS a partir da data da avaliação. Adicionalmente, o PCI SSC realiza o QA para garantir que os PA-QSAs documentaram de forma completa e precisa as avaliações do PA-DSS.

Fornecedores de software

Os fornecedores de software (“fornecedores”) desenvolvem aplicativos de pagamento que armazenam, processam ou transmitem dados do portador do cartão como parte da autorização ou acordo e então vendem, distribuem ou licenciam esses aplicativos de pagamento a terceiros (clientes ou

revendedores/integradores). Os fornecedores são responsáveis pelo seguinte:

 Criação de aplicativos de pagamento em conformidade com o PA-DSS que facilitam e não impedem a conformidade com o PCI DSS dos clientes (o aplicativo não requer uma implementação ou configuração que viole os requisitos do PCI DSS).

 Cumprimento dos requisitos do PCI DSS sempre que o fornecedor armazena, processa ou transmite dados do portador do cartão (por exemplo, durante soluções de problemas com o cliente).

(7)

 Criação de um Guia de implementação do PA-DSS, específico a cada aplicativo, de acordo com os requisitos contidos no Padrão de segurança de dados de aplicativos de pagamento.

 Orientação aos clientes, revendedores e integradores sobre como instalar e configurar os aplicativos de pagamento em conformidade com o PCI DSS.

 Garantindo que os aplicativos de pagamento cumpram os requisitos do PA-DSS ao serem aprovados na análise do PA-DSS conforme especificado em Requisitos do PCI DSS e

Procedimentos de Avaliação de Segurança.

Os fornecedores enviam seus aplicativos de pagamento e documentação de suporte ao PA-QSA para revisão. Quaisquer acordos e custos associados à avaliação são negociados entre o fornecedor e o PA-QSA. Os fornecedores permitem que seus PA-QSA enviem os relatórios de conformidade do PA-DSS resultantes ao PCI SSC.

PA-QSAs

Os QSAs são QSAs que foram qualificados e treinados pelo PCI SSC para realizar revisões do PA-DSS. Observe que nem todos os QSAs são PA-QSAs – existem requisitos de qualificação adicionais que

devem ser atendidos para que um QSA torne-se um PA-QSA.

Os PA-QSAs são responsáveis pelo seguinte:

 Realização de avaliações dos aplicativos de pagamento de acordo com os Procedimentos de avaliação de segurança e os Requisitos de validação do PA-QSA.

 Fornecimento de opiniões indicando se o aplicativo de pagamento atende aos requisitos do PA-DSS.

 Fornecimento da documentação adequada dentro do ROV para demonstrar a conformidade do aplicativo de pagamento com o PA-DSS.

 Envio do ROV ao PCI SSC, junto com o Atestado de validação (assinado pelo PA-QSA e pelo fornecedor).

 Manutenção de um processo de controle de qualidade interno para seus esforços do PA-QSA. É responsabilidade do PA-QSA informar se o aplicativo de pagamento obteve a conformidade. O PCI SSC não aprova ROVs de uma perspectiva técnica de conformidade, mas realiza revisões de QA nos ROVs para garantir que os relatórios documentam corretamente a demonstração da conformidade.

Revendedores e integradores

Revendedores e integradores são as entidades que vendem, instalam e/ou consertam aplicativos de pagamento em nome de fornecedores de software ou outros. Os revendedores e integradores que realizam serviços relacionados aos aplicativos de pagamento em conformidade com o PA-DSS são responsáveis pelo seguinte:

 Implementação somente de aplicativos de pagamento em conformidade com o PA-DSS em um ambiente compatível com o PCI DSS (ou orientação ao comerciante sobre como fazê-lo).

 Configuração de tais aplicativos de pagamento (em que as opções de configuração são fornecidas) de acordo com o Guia de implementação do PA-DSS oferecido pelo fornecedor.

 Configuração de tais aplicativos de pagamento (ou orientação ao comerciante sobre como fazê-lo) em conformidade com o PCI DSS.

 Manutenção de tais aplicativos de pagamento (por exemplo, resolução de problemas, ofertas de atualizações remotas e suporte remoto) de acordo com o Guia de implementação do PA-DSS e o PCI DSS.

Os revendedores e integradores não enviam aplicativos de pagamento para avaliação. Os produtos somente podem ser enviados pelo fornecedor.

(8)

Clientes

Os clientes são comerciantes, provedores de serviço e outros que compram ou recebem um aplicativo de pagamento de terceiro para armazenar, processar ou transmitir dados do portador do cartão como parte da autorização ou acordo de transações de pagamento. Os clientes que desejam usar os aplicativos de pagamento em conformidade com o PA-DSS são responsáveis pelo seguinte:

Observação:

O aplicativo de pagamento compatível com o PA-DSS somente não é garantia de conformidade com o PCI DSS.

 Implementação de um aplicativo de pagamento em conformidade com o PA-DSS em um ambiente compatível com o PCI DSS.

 Configuração do aplicativo de pagamento (em que as opções de configuração são fornecidas) de acordo com o Guia de implementação do PA-DSS oferecido pelo fornecedor.

 Configuração do aplicativo de pagamento em conformidade com o PCI DSS.

 Manutenção do status de conformidade com o PCI DSS para o ambiente e a configuração do aplicativo de pagamento.

Assim que a lista for publicada pelo PCI SSC no segundo semestre de 2008, os clientes poderão encontrar uma listagem dos aplicativos de pagamento validados, junto com outros materiais de referência, no site.

(9)

Considerações do fornecedor – Preparação para a revisão

A quais aplicativos o PA-DSS se aplica?

Para as finalidades do PA-DSS, um aplicativo de pagamento é definido como um que armazena, processa ou transmite dados do portador do cartão como parte da autorização ou acordo, em que os aplicativos de pagamento são vendidos, distribuídos ou licenciados a terceiros.

O seguinte guia pode ser utilizado para determinar se o PA-DSS aplica-se a um determinado aplicativo:  O PA-DSS destina-se a aplicativos de pagamento que geralmente são vendidos e instalados de

forma pré-definida sem muita personalização dos fornecedores de software.

 O PA-DSS destina-se a aplicativos de pagamento fornecidos em módulos, que geralmente incluem um módulo “base” e outros específicos aos tipos ou às funções do cliente, ou personalizados conforme a solicitação do cliente. O PA-DSS pode destinar-se apenas ao módulo base se esse módulo for o único que realiza funções de pagamento (assim que confirmado por um PA-QSA). Se os outros módulos também realizarem funções de pagamento, o PA-DSS também irá aplicar-se a esses módulos. Observe que isso é considerado uma “prática recomendada” para fornecedores de software de modo a isolar as funções de pagamento em um único ou pequeno número de módulos base, reservando os outros para funções que não sejam de pagamento. Essa prática

recomendada (embora não seja um requisito) pode limitar o número de módulos sujeitos ao PA-DSS.

 O PA-DSS NÃO se destina a aplicativos de pagamento desenvolvidos e vendidos somente para um cliente, pois esse aplicativo será coberto como parte da revisão de conformidade normal do PCI DSS do cliente. Observe que tal aplicativo (que pode ser referido como um aplicativo “sob medida”) é vendido apenas a um cliente (geralmente um grande comerciante ou fornecedor de serviços) e é projetado e desenvolvido de acordo com as especificações fornecidas pelo cliente.  O PA-DSS NÃO se destina a aplicativos de pagamento desenvolvidos por comerciantes e

fornecedores de serviço se utilizados apenas internamente (não vendido, distribuído ou licenciado a terceiros), visto que esse aplicativo de pagamento desenvolvido internamente deveria ser

coberto como parte da conformidade normal do comerciante ou fornecedor de serviço do PCI DSS.

Por exemplo, para os últimos itens anteriores, caso o aplicativo de pagamento desenvolvido

internamente ou sob medida armazene dados de autenticação confidenciais proibidos ou permita que senhas complexas sejam cobertas como parte dos esforços de conformidade normal do comerciante ou do fornecedor de serviço do PCI DSS e não exijam uma avaliação separada do PA-DSS.

A lista a seguir, embora não seja totalmente inclusiva, ilustra os aplicativos que NÃO são aplicativos de pagamento para a finalidade do PA-DSS (e, portanto, não precisam passar pelas revisões do PA-DSS):

 Sistemas operacionais nos quais o aplicativo é instalado (por exemplo, Windows, Unix).

 Sistemas de bancos de dados que armazenam dados de portador de cartão (por exemplo, Oracle).

 Sistemas de back-office que armazenam dados do portador do cartão (por exemplo, para emissão de relatórios ou serviços ao cliente).

Observação:

O PCI SSC listará SOMENTE os aplicativos que são de pagamento.

Antes da revisão

 Revise os requisitos do PCI DSS e do PA-DSS e a documentação relacionada disponível no site.  Determine/analise a facilidade do aplicativo de pagamento em relação à conformidade com o

(10)

 Realize uma análise de “lacuna” entre como o aplicativo de pagamento se sujeita às funções do PA-DSS em comparação aos requisitos do PA-DSS.

 Corrija qualquer lacuna.

 Se desejado, o PA-QSA pode realizar uma pré-avaliação ou análise de “lacuna” no aplicativo de pagamento de algum fornecedor. Se o PA-QSA observar deficiências que podem impedir uma opinião clara, o PA-QSA oferecerá ao fornecedor de software uma lista dos recursos do aplicativo de pagamento a serem atendidos antes do início do processo de revisão formal.  Determine se o Guia de implementação do PA-DSS atende aos requisitos do PA-DSS.

Documentação e materiais necessários

Como requisito para a avaliação, o fornecedor de software deve oferecer a documentação e o software apropriados ao PA-QSA.

Todos os documentos e informações relevantes ao PA-DSS podem ser baixados no site. Todos os materiais relacionados ao aplicativo de pagamento como CDs de instalação, manuais, o Guia de

implementação do PA-DSS, etc. relacionados à realização da revisão devem ser enviados a um PA-QSA

listado no site, não ao PCI SSC. Informações específicas à revisão devem ser solicitadas diretamente ao PA-QSA.

Exemplos de documentos e itens a enviar ao PA-QSA incluem:

1. O aplicativo de pagamento com o manual do operador ou instruções.

2. Os acessórios de hardware e software necessários para realizar transações de pagamento simuladas.

3. A documentação que descreve todas as funções utilizadas para entrada e saída de dados que podem ser usadas pelos desenvolvedores de aplicativos terceirizados. Especificamente, as funções associadas à captura, autorização, acordo e fluxos de chargeback (se for o caso do aplicativo) devem ser descritas. (Um manual é exemplo de documentação que pode atender a esse requisito.)

4. A documentação que se relaciona à instalação e configuração do aplicativo ou que fornece informações sobre o aplicativo. Exemplos de tais documentações incluem:

 Guia de implementação do PA-DSS

 Guia de instalação do software ou instruções (conforme fornecido aos clientes).  Esquema de enumeração da versão do fornecedor.

 Alteração na documentação de controle que mostra como as alterações são ilustradas aos clientes.

5. Documentação adicional – como diagramas e fluxogramas – que auxiliam na revisão do aplicativo de pagamento (o PA-QSA pode solicitar material adicional quando necessário.)

Programações da revisão do PA-DSS

O período necessário para uma revisão do PA-DSS, desde o início até a conclusão resultando em um aplicativo totalmente validado com todos os itens anotado como “Implementado”, pode variar

amplamente. Os fatores que determinam o período incluem:

 A que proximidade da conformidade com o PA-DSS o aplicativo está no início da revisão.

 Correções ao aplicativo de pagamento para obter conformidade que expandem o período de tempo.

(11)

 Reedições extensas do Guia que expandem o período de tempo.

 Se o PA-QSA prepara e envia um ROV do PA-DSS de alta qualidade ao PCI SSC.

 Se o PCI SSC revisa o relatório mais de uma vez, retornando comentários ao PA-QSA para cada questão, isso expande o período de tempo.

Qualquer programação de revisão informada por um PA-QSA deve ser considerada como estimativa, visto que pode estar baseada na suposição de o aplicativo de pagamento poder atender com êxito e rapidez a todos os requisitos do PA-DSS. Se forem encontrados problemas durante os processos de revisão ou aceitação, será necessário realizar discussões entre o PA-QSA, o fornecedor de software e/ou o PCI SSC. Tais discussões podem gerar impacto nos tempos de revisão e causar atrasos e/ou podem até mesmo fazer com que a revisão termine prematuramente (se, por exemplo, o fornecedor decidir que não deseja fazer as alterações necessárias no aplicativo de pagamento para atingir a conformidade).

Assessores de segurança qualificados do aplicativo de pagamento

O PCI SSC qualifica e treina os Assessores de segurança qualificados do aplicativo de pagamento (PA-QSAs) para realizar avaliações do PA-DSS. Os PA-QSAs estão listados site. Esses são os únicos assessores reconhecidos pelo PCI SSC como aptos para realizar as avaliações do PA-DSS. Os preços e as taxas cobradas pelos PA-QSAs não são definidas pelo PCI SSC; essas taxas são negociadas entre o PA-QSA e seu cliente. Antes de escolher o PA-QSA, é recomendável que as

entidades entrem em contato com várias empresas de PA-QSA e acompanhem os processos de seleção do fornecedor de suas empresas.

Serviços do PA-DSS relacionados que podem ser oferecidos pelos

PA-QSAs

Nenhum desses serviços é exigido ou recomendado pelo PCI SSC. Essa lista está incluída para fornecer exemplos dos tipos de serviços que podem ser oferecidos pelo PA-QSAs. Se esses serviços são de interesse de sua empresa, entre em contato com os PA-QSAs para saber a disponibilidade e os preços. Exemplos dos serviços relacionados dos PA-DSS incluem:

 Orientação sobre a criação de aplicativos de pagamento de acordo com o PA-DSS.

 Revisão do projeto de software do fornecedor, resposta a perguntas por e-mail ou telefone e participação em chamadas de conferência para esclarecer requisitos.

 Orientação sobre como preparar o Guia de implementação do PA-DSS.

 Serviços de pré-avaliação (análise de “lacunas”) antes do início da avaliação formal do PA-DSS.  Orientação sobre como deixar o aplicativo de pagamento em conformidade com o PA-DSS se

forem observadas lacunas ou áreas de inconformidade durante a avaliação.

Suporte técnico durante os testes

É recomendável que o fornecedor disponibilize um contato de recurso técnico para auxiliar no caso de dúvidas que possam surgir durante a avaliação. Durante a revisão, e para acelerar o processo, um contato do fornecedor deve estar disponível para discutir problemas e responder às dúvidas do PA-QSA.

Acordo de liberação e entrega do relatório

Antes de o PA-QSA liberar o relatório do PA-DSS ao PCI SSC, o fornecedor deve assinar o Acordo de liberação do fornecedor do PA-DSS do setor de cartões de pagamento do PCI SSC (o “Acordo de liberação”), dando permissão para a liberação do relatório ao PCI SSC para revisão. O Acordo de liberação deve ser entregue diretamente ao PCI SSC pelo QSA, junto com os relatórios do PA-DSS.

(12)

Taxas

Observação:

O fornecedor paga todas as taxas de avaliação do PA-DSS diretamente ao PA-QSA (essas taxas são negociadas entre o fornecedor e o PA-QSA). O PCI SSC cobrará do fornecedor a cada trimestre todas as taxas de listagem e o

fornecedor irá pagar essas taxas de listagem diretamente ao PCI SSC.

Todas as taxas e datas relacionadas às avaliações do PA-DSS do PA-QSA são negociadas entre o PA-QSA e o fornecedor do aplicativo de pagamento, e o fornecedor paga todas as taxas diretamente ao PA-QSA.

Será cobrada dos fornecedores uma taxa de listagem anual de $1.250 para cada aplicativo de pagamento na lista de aplicativos do PCI SSC.

Como parte do processo de Revalidação anual (consulte a seção

“Revalidação anual” posteriormente neste documento), a taxa de listagem será cobrada anualmente pelo PCI SSC a fornecedores de software para todos os aplicativos de pagamento listados pelo PCI SSC para esse

fornecedor na data de vencimento. Essa data será definida trimestralmente, com base do trimestre da listagem original. Por exemplo, em 1º de abril, será cobrada dos fornecedores de software uma taxa de $1.250 pelo aplicativo de pagamento listado a partir de trimestre encerrado em 31 de março. Os fornecedores não serão cobrados pelos aplicativos validados mas para os quais o fornecedor de software optar por não listar o produto no site. Observe que os fornecedores não poderão manipular as listagens para evitar a taxa. Ou seja, os fornecedores não podem fazer com que um aplicativo seja removido da lista e então recolocá-lo na lista após a cobrança.

(13)

Visão geral dos processos do PA-DSS

O processo de revisão do PA-DSS é iniciado pelo fornecedor. O site possui todos os documentos associados dos quais o fornecedor irá precisar para navegar pelo processo de revisão do PA-DSS. O fornecedor seleciona um PA-QSA da lista do PCI SSC e negocia o custo e o NDA com o PA-QSA. Em seguida, o fornecedor providencia o software do aplicativo de pagamento, os manuais e outros documentos necessários para o |PA-QSA. O PCI SSC emitirá uma carta de aceitação confirmando a conclusão bem-sucedida do processo para cada aplicativo de pagamento (uma “Carta de aceitação do PA-DSS”). Assim que o aplicativo de pagamento for aceito, o produto será listado no site.

As ilustrações e as descrições nas páginas a seguir explicam em detalhe os seguintes componentes do programa do PA-DSS:

Processo Ilustração Nº da página

Processo de aceitação do relatório do PA-DSS Figura 1 12

Alterações do PA-DSS nos aplicativos listados Figura 2 13

Grandfathering e transição dos aplicativos PABP à lista PA-DSS Figura 3 14

Revalidação anual e renovação de aplicativos expirados do PA-DSS Figura 4 15

(14)

(15)

(16)

(17)

(18)

(19)

Visão geral do processo de aceitação do relatório do PA-DSS

Observe que todos os relatórios do PA-DSS e outros materiais devem ser enviados ao PCI SSC em inglês.

O PA-QSA realiza a revisão do aplicativo de pagamento de acordo com os

Procedimentos de avaliação de segurança do PA-DSS e gera um relatório que

é compartilhado com o fornecedor. Se o relatório estiver com todos os itens “Implementado”, o fornecedor assina o Acordo de liberação e o relatório é enviado pelo PA-QSA ao PCI SSC. Se o relatório não possuir todos os itens “Implementado”, então o fornecedor deverá solucionar esses itens destacados no relatório. Por exemplo, isso pode incluir atualização da documentação do usuário ou do software. Assim que o PA-QSA estiver certo de que todos os itens foram solucionados pelo fornecedor, o fornecedor assina o Acordo de

liberação e o relatório é enviado pelo PA-QSA ao PCI SSC.

O PCI SSC recebe o relatório e o revisa por uma perspectiva de controle de qualidade. Se o relatório atender aos requisitos de controle de qualidade, conforme documentado nos Requisitos de validação do QSA e nos documentos de apoio, o PCI SSC envia uma Carta de aceitação do PA-DSS ao fornecedor e adiciona o aplicativo à lista do PCI SSC até o final do mês para os aplicativos finalizados até o dia 10 desse mês. No caso de problemas de qualidade associados ao relatório, o PCI SSC comunica esses problemas ao PA-QSA. É responsabilidade do PA-QSA resolver esses problemas com o PCI SSC. Os problemas podem se limitar à atualização do relatório para refletir a documentação adequada de modo a apoiar as decisões do PA-QSAs. No entanto, se os problemas exigirem que o PA-QSA realize mais testes, então o PA-QSA deverá notificar o fornecedor que o novo teste é necessário e agendar esse teste.

(20)

Alterações aos aplicativos de pagamento listados

Os fornecedores atualizam os aplicativos de pagamento listados anteriormente por vários motivos, por exemplo, para adicionar funcionalidade auxiliar ou fazer upgrade do aplicativo base ou principal. Da perspectiva do PA-DSS, existem três tipos essenciais de alterações:

1. Sem impacto nos requisitos do PA-DSS de pequenas alterações feitas no aplicativo de pagamento listado. Nesse caso, para a nova versão a ser listada, o fornecedor do software documenta a alteração para a revisão do PA-QSA – consulte a seção Sem impacto nos

requisitos do PA-DSS para saber as especificações.

2. Possível impacto nos requisitos do PA-DSS de alterações feitas no aplicativo de pagamento listado. Nesse caso, para a nova versão a ser listada, o fornecedor do software envia a nova versão do aplicativo de pagamento para uma revisão completa do PA-DSS – consulte a seção

Possíveis impactos nos requisitos do PA-DSS para saber as especificações.

3.

Sem alterações no aplicativo de pagamento listado. Nesse caso, é necessário somente um formulário de atestado anual – consulte a seção Sem alterações no aplicativo de pagamento

listado para saber as especificações.

Em tais casos em que as atualizações são realizadas em aplicativos listados anteriormente e o

fornecedor deseja que as informações do aplicativo de pagamento atualizado sejam refletidas na lista, o fornecedor deverá enviar os detalhes dessas alterações ao PA-QSA, de preferência ao PA-QSA que originalmente revisou o aplicativo de pagamento.

O PA-QSA determinará se é necessária uma nova avaliação do aplicativo de pagamento. Essa decisão pode se basear no possível impacto na segurança das alterações feitas ao aplicativo. Outra

consideração pode ser o escopo ou a amplitude das alterações que estão sendo feitas. Por exemplo, a alteração pode impactar somente funcionalidades auxiliares e não causar qualquer impacto no aplicativo de pagamento principal.

Se o aplicativo de pagamento tiver sofrido alterações que podem afetar os requisitos do PA-DSS, e/ou se o fornecedor desejar que as

informações em sua Carta de aceitação do PA-DSS e no site sejam revisadas, o fornecedor deverá enviar a documentação com a alteração apropriada para que o PA-QSA determine se será necessário realizar uma avaliação completa. Se o PA-QSA concordar com o fornecedor que as alterações documentadas não causam impactos nos requisitos do PA-DSS, o PA-QSA irá comunicar o fornecedor do software e o fornecedor irá preparar e assinar um formulário de Auto-atestado de alterações, que o PA-QSA também assinará, e irá enviar ao SSC. O PCI SSC irá publicar as atualizações de acordo em sua Carta de

aceitação do PA-DSS revisada e no site. Veja abaixo em Sem impacto nos requisitos do DSS: Não é necessária uma nova revisão do PA-DSS para obter mais informações.

Observação:

Se os fornecedores do aplicativo de pagamento puderem modularizar a funcionalidade de

pagamento, isso ajudará a minimizar a necessidade de novas avaliações devido às alterações que não geram impacto na funcionalidade e na segurança do pagamento. O fluxo do processo para alterações aos aplicativos listados é detalhado na Figura 2.

Sem impacto nos requisitos do PA-DSS: Não é necessária uma nova revisão do

PA-DSS

Se algum aplicativo de pagamento listado previamente for revisado, mas essa revisão for considerada pequena e não afetar negativamente a segurança, a documentação da alteração (uma “Análise da alteração”) pode ser enviada ao PA-QSA para revisão. É altamente recomendável que o fornecedor utilize o mesmo PA-QSA que foi usado na avaliação original.

A Análise da alteração enviada pelo fornecedor do software ao PA-QSA deve conter no mínimo as seguintes informações:

(21)

 Número da versão do aplicativo de pagamento.

 Nome e número de versão do aplicativo de pagamento relacionado atualmente na lista do PCI SSC.

 Descrição da alteração.

 Descrição do motivo pelo qual a alteração é necessária.

 Detalhes dos possíveis impactos nos dados do portador do cartão e funções de pagamento e quais são esses impactos.

 Descrição de como a alteração funciona.

 Descrição do teste realizado pelo fornecedor para validar se os requisitos de segurança do PA-DSS não são afetados negativamente.

 Explicação de como e por que os requisitos do PA-DSS não são afetados negativamente.  Descrição da forma como a alteração se ajusta à metodologia de versão do fornecedor,

incluindo como esse número de versão indica que é uma alteração “pequena”.

 Se aplicável, descrição do uso de abordagens de práticas/módulo de programação e como tais usos evitam impactos negativos nos requisitos.

Se o PA-QSA concordar que a alteração documentada na Análise de alteração feita pelo fornecedor não afeta negativamente a segurança do aplicativo de pagamento, (i) o PA-QSA irá notificar o fornecedor do software, (ii) o fornecedor do software irá preparar e assinar um Auto-atestado da alteração e irá enviar ao PA-QSA, (iii) o PA-QSA irá assinar para confirmar sua concordância e o encaminhará, junto com a Análise da alteração, ao PCI SSC, e (iv) o PCI SSC irá revisar o formulário e a documentação para fins de controle de qualidade.

Considerando que não há impactos aos requisitos do PA-DSS:

 Uma Carta de aceitação do PA-DSS revisada será emitida ao fornecedor.

 A Lista de aplicativos de pagamento validados pelo PA-DSS disponível no site será atualizada de acordo com as novas informações.

 A data de vencimento desse aplicativo listado recentemente e o número de versão serão os mesmos do aplicativo de pagamento “pai”.

Para problemas de qualidade associados ao Auto-atestado da alteração, o PCI SSC comunica esses problemas ao PA-QSA e tais questões são resolvidas de acordo com os processos descritos

anteriormente.

Possíveis impactos nos requisitos do PA-DSS: Necessária uma nova revisão do

PA-DSS

Se as alterações ao aplicativo de pagamento gerarem impacto nos requisitos do PA-DSS, o aplicativo de pagamento deverá passar por outra avaliação do PA-DSS. O PA-QSA irá então enviar um novo relatório do PA-DSS ao PCI SSC para sua aceitação. Nesse caso, o fornecedor deverá primeiramente enviar a documentação da alteração ao PA-QSA, que irá determinar se a natureza da alteração causará impactos na segurança do aplicativo de pagamento, de acordo com os requisitos atuais do PA-DSS.

Alterações aos aplicativos de pagamento listados: Revalidação anual necessária

Anualmente, até a data de revalidação anotada na lista, o fornecedor do software precisa enviar um formulário de Atestado de validação com a parte 3b preenchida. Esse formulário está localizado no Anexo C do PA-DSS.

(22)

Renovação de aplicativos expirados

Conforme o aplicativo se aproxima da data de vencimento, o PCI SSC notificará o fornecedor do software sobre o vencimento pendente. As duas opções disponíveis para consideração do fornecedor são:

1. O fornecedor deseja continuar a usar o aplicativo. Se for o caso, o fornecedor entra em contato com o PA-QSA e solicita que o aplicativo de pagamento seja reavaliado.

2. O fornecedor não continuará a vender o aplicativo. Se for o caso, o PCI SSC alterará o status listado do aplicativo de pagamento para “Não aceitável para novas implantações” depois da data de vencimento.

Observe que se o fornecedor optar por continuar a vender o aplicativo, assim que o processo de avaliação do PA-DSS for concluído com êxito novamente, ficará mantido o status na lista do PCI SSC como “aceitável para novas implantações” e será atribuída uma nova data de vencimento.

(23)

Transição e grandfathering de aplicativos de pagamento

validados pelo PABP

Grandfathering de aplicativos do PABP na lista do PABP até 15 de outubro de

2008

O PCI SSC está grandfathering (transferindo) aplicativos existentes compatíveis com o PABP para a lista do PCI SSC. Essa abordagem de grandfathering permite que os aplicativos que foram avaliados previamente e considerados em conformidade com o PABP continuem sendo desenvolvidos até que novos aplicativos de pagamento, compatíveis com o PA-DSS, estejam disponíveis.

Uma abordagem em fases foi aplicada às datas de vencimento dos aplicativos PABP, dependendo da versão dos requisitos utilizados para avaliar o aplicativo. Para permanecer na lista do PCI SSC como “aceitável para novas implantações”, os aplicativos compatíveis com o PABP precisam ser avaliados em relação ao PA-DSS dentro da programação determinada. Se o aplicativo compatível com o PABP não for avaliado em relação ao PA-DSS dentro da programação determinada, esse aplicativo continuará na lista do PCI SSC, mas com a observação “não aceitável para novas implantações”.

Observação:

A lista do PCI SSC distingue entre “novas implantações” e

“implantações existentes”. Geralmente os aplicativos de pagamento possuem um ciclo de vida mais longo assim que são implantados, até 10-15 anos. O PCI SSC entende que a implantação de aplicativos de pagamento pode ser um processo complexo e

dispendioso e que pode não ser prático para que comerciantes e adquirentes atualizem seus aplicativos de pagamento a cada poucos anos.

A tabela a seguir mostra as respectivas datas de vencimento e observações que serão incluídas na Lista

de aplicativos de pagamento validados pelo PA-DSS para as versões do PABP e revisões do PA-DSS,

de acordo com o atual PA-DSS v1.1.

Listagem do PCI SSC antes da expiração

Listagem do PCI SSC após a expiração Versão Data de vencimento Notas de validação Notas de implantação Notas de validação Notas de implantação

PABP 1.4 24 meses Validada de

acordo com o PABP

Aceitável para novas implantações Validada de acordo com o PABP Inaceitável para novas implantações

PABP 1.3 18 meses Validada de

acordo com o PABP

Aceitável para novas implantações Validada de acordo com o PABP Inaceitável para novas implantações Antes do PABP 1.3 12 meses Aplicativo pré-PCI Não recomendável para novas implantações Aplicativo pré-PCI Inaceitável para novas implantações PA-DSS 1.1 3 anos após a alteração ao padrão Validada de acordo com o PA-DSS

Aceitável para novas implantações Validada de acordo com o PA-DSS Inaceitável para novas implantações

O fluxo do processo para grandfathering e transição dos aplicativos do PABP é detalhado na Figura 3.

Aplicativos de pagamento que passarão pelas revisões do PABP durante a transição

No lançamento do PA-DSS versão 1.1, foi iniciado um período de carência de aproximadamente seis meses durante o qual os PA-QSAs poderão conhecer os novos padrões, receber treinamento e qualificar-se para realizar novas revisões do PA-DSS. Além disso, os fornecedores podem usar esse período para conhecerem o PA-DSS e atender aos novos requisitos do PA-DSS no desenvolvimento de novos aplicativos de pagamento.

(24)

Durante o período de carência, os aplicativos de pagamento podem continuar a ser avaliados em relação à Versão 1.4 do PABP. O período de carência estende-se até 15 de outubro de 2008. Os relatórios que forem enviados após esse período não serão aceitos para validação de conformidade do PABP.1

Os relatórios baseados na versão 1.4 do PABP que forem enviados até 15 de outubro de 2008 precisam passar pelos Procedimentos de transição do PA-DSS. O PA-QSA pode usar os resultados do relatório do PABP, mas também deve incluir uma avaliação delta de acordo com os Procedimentos de transição do

PA-DSS em seu envio ao PCI SSC.

O fornecedor também poderá optar por avaliar seu aplicativo de pagamento de acordo com o PA-DSS a qualquer momento após o lançamento do novo padrão.

Procedimentos de transição do PA-DSS

Os Procedimentos de transição do PA-DSS devem ser utilizados pelos Assessores de segurança qualificados do aplicativo de pagamento (PA-QSAs), onde aplicável, para efetuar a transição de um aplicativo da lista da Visa de Aplicativos de pagamento validados pelo PABP2 para a lista do PCI SSC de Aplicativos de pagamento validados pelo PA-DSS3.

Observação: O PCI SSC está “grandfathering” (ou transferindo) os aplicativos de pagamento validados de

acordo com o PABP Versões 1.3 e 1.4 para a lista de aplicativos validados pelo PA-DSS durante 18 ou 24 meses, respectivamente, antes que seja exigida uma revisão do PA-DSS.

Esses Procedimentos de transição são aplicáveis nos seguintes casos: Conclusão obrigatória dos procedimentos de transição: Se o aplicativo de pagamento estiver passando por uma revisão do PABP que não foi concluída e aceita pela Visa antes de 15 de outubro de 2008, a conclusão desses procedimentos de transição torna-se obrigatória para que o PCI SSC reconheça esses aplicativos como validados de acordo com o PA-DSS. Observe que as revisões realizadas exclusivamente de acordo com o PABP NÃO serão aceitas depois de 15 de outubro de 2008.

Observação:

A mesma empresa PA-QSA utilizada para realizar a revisão PABP deve ser utilizada para realizar os Procedimentos de transição do PA-DSS.

Conclusão voluntária dos procedimentos de transição: De acordo com a Observação anterior, se o fornecedor do aplicativo de pagamento possuir aplicativos elegíveis para “grandfathering”, mas desejar que algum aplicativo do PABP Versão 1.3 ou 1.4 seja listado como “Validado de acordo com o PA-DSS”, esses procedimentos de transição deverão ser utilizados. Um PA-QSA deverá realizar esses procedimentos e enviar o relatório de acordo com o Guia de programa do PA-DSS para que o PCI SSC reconheça os aplicativos do PABP Versão 1.3 e 1.4 como validados.

Para obter mais informações sobre os Procedimentos de transição do PA-DSS, consulte os

Procedimentos de transição do PABP ao PA-DSS disponível no site.

1_{Se algum aplicativo de pagamento for avaliado em relação à Versão 1.4 do PABP e enviado antes de 15 de}

outubro de 2008, e houver problemas de qualidade com o relatório, será aberta uma exceção. Esse aplicativo poderá continuar sua revisão de acordo com a Versão 1.4 do PABP até que os problemas de qualidade sejam resolvidos. As exceções desse tipo são permitidas até 15 de abril de 2009.

2_{Revisado conforme as Melhores práticas do aplicativo de pagamento (PABP), Versões 1.3 ou 1.4.}

(25)

Programa de controle da qualidade

O PCI SSC revisa os relatórios do PA-QSA para fins de controle de qualidade. Conforme informado nos

Requisitos de validação do QSA e no Acordo do PA-QSA, os PA-QSAs precisam atender aos padrões de

controle de qualidade definidos pelo PCI SSC. As várias fases do programa de QA são descritas a seguir.

O fluxo do processo para o programa de QA é detalhado na Figura 5.

Novo programa de amostragem do PA-QSA

O PCI SSC utiliza um processo de amostragem em fases para revisar os ROVs dos PA-QSAs – inicialmente mais relatórios são revisados, e conforme o PA-QSA demonstra qualidade a taxa de amostragem é reduzida. Conforme o PA-QSA continua a atender aos padrões de qualidade, eles passam para o Programa de amostragem experiente do QSA (com ainda menos taxas de amostragem). Contanto que o PA-QSA atenda aos requisitos de qualidade, eles estarão sujeitos à amostragem limitada.

No entanto, se o PA-QSA não atender aos padrões, as seguintes ações são tomadas:

 Carta de aviso – enviada ao PA-QSA como uma declaração inicial de que o PA-QSA precisa melhorar a qualidade.

 Retificação – se os padrões de qualidade ainda não estiverem sendo atendidos, o PA-QSA é colocado em fase retificação, e ações de punição podem ser iniciadas.

 Revogação – se os padrões de qualidade ainda não estiverem sendo atendidos, o PA-QSA é revogado e removido da lista do PCI SSC de PA-QSAs aprovados.

Programa de amostragem experimental do PA-QSA

Assim que o PA-QSA entrar no Programa de amostragem experimental do PA-QSA, é realizada uma amostragem limitada em seus relatórios. Se os padrões de qualidade continuarem a ser atendidos, a amostragem limitada continua. Isso se destina a ser o “estado fixo” no qual os PA-QSAs trabalham. Se surgirem problemas de qualidade e os padrões não forem atendidos, então o PA-QSA voltará para o Novo programa de amostragem do PA-QSA.

Retificação

Durante a retificação, os PA-QSAs ainda podem realizar revisões, mas todos os relatórios são revisados para fins de QA pelo PCI SSC. O PCI SSC cobrará $500 por cada relatório enviado e reenviado durante esse período.

O PA-QSA também deve enviar um plano de remediação ao PCI SSC detalhando como o PA-QSA planeja melhorar a qualidade de seus relatórios. O PCI SSC também poderá exigir uma visita no local com o PA-QSA para efetuar uma auditoria do seu programa de QA, às custas do PA-QSA.

Se o PA-QSA atender aos requisitos de qualidade durante o período de retificação, ele passará novamente ao Novo programa de amostragem do PA-QSA. Se o PA-QSA não atender aos requisitos durante o período, passará para o estado Revogado.

Observe que se um aplicativo de pagamento incluído na Lista do PCI SSC de aplicativos de pagamento

validados estiver comprometido devido a um erro do PA-QSA, esse PA-QSA deverá ser colocado

imediatamente no período de retificação. O PA-QSA precisará atender aos requisitos de qualidade para voltar para o Novo programa de amostragem do PA-QSA.

(26)

Revogação

Quando um PA-QSA for revogado, ele é removido da lista do PCI SSC de PA-QSAs aprovados. Assim que um QSA for revogado, o QSA não poderá mais revisar os aplicativos de pagamento. O PA-QSA pode recorrer da revogação, mas deverá atender aos requisitos conforme documentado nos Requisitos de validação do QSA e nas documentações de apoio. O PCI SSC reserva-se o direito de exigir uma avaliação de simulação.

Antes de entrar novamente no Programa de amostragem do PA-QSA, será cobrada uma taxa para recolocação na lista de $1.250.

(27)

Processos de relatórios do PA-DSS

O PCI SSC irá aceitar o relatório somente com base nos resultados documentados no ROV. Após o recebimento do relatório, o seguinte irá aplicar-se:

 O PCI SSC deverá revisar o relatório (geralmente dentro de trinta dias após o recebimento) e determinar se é aceitável.

 Se não forem identificados problemas ou questões ao PA-QSA, o PCI SSC cobrará do fornecedor de software uma taxa de listagem. Assim que a taxa for recebida, o PCI SSC emitirá uma Carta de aceitação do PA-DSS e publicará as informações do aplicativo de pagamento e do fornecedor no site.

 Se forem identificados problemas ou questões enviados ao PA-QSA, o processo descrito acima reiniciará após o recebimento de um relatório ou resposta revisado, completo e aceitável (“Relatório revisado”), do PA-QSA. O reinício do processo não ocorre até o recebimento de um Relatório revisado aceitável tratando de todas as questões previamente identificadas mas que estavam em aberto. Geralmente o PCI SSC analisa o Relatório revisado dentro de quatorze dias após o recebimento.

 Caso surjam dúvidas ou problemas adicionais, o ciclo repetirá até que uma resposta satisfatória seja recebida, quando o PCI SSC emitirá a Carta de aceitação do PA-DSS e publicará as informações no site. Questões ou problemas adicionais podem ser levantados a qualquer momento antes da emissão da Carta de aceitação do PA-DSS.

Para relatórios relacionados a alterações a versões de aplicativos listadas existentes, com base no Auto-atestado da alteração do fornecedor, o processo do Relatório de aceitação do PA-DSS descrito

anteriormente é o mesmo, e o PCI SSC deverá emitir uma Carta de aceitação do PA-DSS revisada e publicar as informações atualizadas no site de forma semelhante à mencionada anteriormente, a menos que surjam questões ou problemas.

A carta de aceitação do PCI SSC e a listagem no site conterá, no mínimo, as seguintes informações. Cada característica é detalhada no “Anexo A: Elementos do aplicativo para listagem de aplicativos de

pagamento validados pelo PA-DSS”.

Observação:

O PCI SSC não concederá qualquer “aprovação parcial” com base na capacidade de o aplicativo de pagamento atender a alguns, mas não todos, os requisitos.

 Fornecedor do aplicativo de pagamento  Identificador do aplicativo de pagamento  Número de aprovação

 Notas de validação  Notas de implantação

 Auto-atestado para pequena alteração de versão, se aplicável

 Data de revalidação anual  Data de vencimento  Empresa do PA-QSA

 Tipo de aplicativo de pagamento

 Mercado-alvo do aplicativo de pagamento, se aplicável

(28)

Notificação após uma quebra na segurança ou comprometimento

Os fornecedores devem notificar o PCI SSC sobre qualquer quebra ou comprometimento na segurança que ocorra em relação ao aplicativo de pagamento listado, procedendo conforme descrito nesta seção.

Notificação e programação

Apesar de qualquer outra obrigação legal que o fornecedor possa ter, ele deve notificar imediatamente o PCI SSC de qualquer quebra ou

comprometimento na segurança em relação a qualquer aplicativo de pagamento do fornecedor listado pelo PCI SSC.

O fornecedor também deverá informar imediatamente qualquer impacto (potencial ou real) que a quebra gerou, pode gerar ou irá gerar.

Observação:

A notificação deverá ocorrer não mais do que 24 horas após a descoberta da quebra na segurança ou comprometimento.

Formato da notificação

A notificação inicial do fornecedor de uma quebra de segurança ou comprometimento deverá ser feita por telefone, para o Coordenador do PA-DSS do PCI SSC, seguida de um e-mail, fax ou carta

informando todos os detalhes do ocorrido.

Detalhes da notificação

Após a notificação da quebra de segurança ou comprometimento, o fornecedor deverá informar ao Coordenador do PA-DSS do PCI SSC todos os dados relevantes relacionados ao ocorrido. Isso deverá incluir, sem limitações:

 Os números das contas comprometidas (caso tenha conhecimento).

 Qualquer relatório detalhando a quebra ou comprometimento na segurança.

 Qualquer relatório ou avaliação realizada para investigar a quebra ou comprometimento na segurança.

O PCI SSC, conforme os termos do Acordo de liberação, deverá compartilhar essas informações e outras, conforme a necessidade, para ajudar ou possibilitar uma avaliação da quebra de segurança ou comprometido a ser realizada para amenizar ou impedir outras quebras e comprometimentos.

Ações após uma quebra na segurança ou comprometimento

Caso o PCI SSC seja notificado sobre uma falha na segurança ou comprometimento real relacionado a um produto específico, ou grupo de produto, conforme relacionado na Lista de aplicativos de pagamento

validados pelo PA-DSS, o PCI SSC deverá tomar as seguintes medidas:

 Notificar todas as bandeiras que ocorreu uma quebra ou comprometimento na segurança.  Tentar obter o relatório forense para avaliar exatamente como ocorreu o comprometimento.  Entrar em contato com o fornecedor para informar que o seu produto possui uma falha na

segurança ou que está comprometido e, quando possível, compartilhar as informações relacionadas à falha ou ao comprometimento real.

 Apoiar os esforços do fornecedor na tentativa e amenização ou impedir outros comprometimentos.  Apoiar os esforços do fornecedor na 1) correção de qualquer quebra na segurança e 2) produção

de um documento de orientação a ser emitido aos clientes do fornecedor, informando sobre qualquer possível vulnerabilidade e detalhando quais ações devem ser tomadas para amenizar ou impedir novas quebras na segurança ou comprometimentos.

 Trabalhar com as agências legais apropriadas para ajudar a amenizar ou impedir outros comprometimentos.

 Apoiar e/ou possibilitar avaliações do produto comprometido, seja internamente ou sob os termos do Acordo de liberação, usando os PA-QSAs para identificar a causa do comprometimento.

(29)

Cancelamento da aprovação

O PCI SSC reserva-se o direito de cancelar a aceitação do aplicativo de pagamento e remover esse aplicativo da Lista de aplicativos de pagamento validados pelo PA-DSS, quando ficar claro que esse aplicativo não oferece proteção suficiente contra as ameaças atuais e/ou não está em conformidade com os requisitos do PA-DSS. Se o PCI SSC considerar que o aplicativo de pagamento possui uma falha na segurança ou foi comprometido, o PCI SSC irá notificar o fornecedor por escrito, informando sua intenção de cancelar a aceitação do aplicativo de pagamento.

(30)

Termos e condições legais

A aprovação do PCI SSC destina-se somente a aplicativos/versões de pagamento que são idênticos aos aplicativos de pagamento revisados por um PA-QSA. Se qualquer aspecto do aplicativo de pagamento for diferente do que foi testado pelo PA-QSA – mesmo se o aplicativo de pagamento estiver em conformidade com a descrição básica do produto contida na carta, o aplicativo não deverá ser considerado como aceito pelo PCI SSC, nem promovido como aceito pelo PCI SSC. Por exemplo, se algum aplicativo de pagamento possuir o mesmo nome ou número de versão que aqueles testados pelo PA-QSA, mas na realidade não for idêntico ao aplicativo revisado pelo PA-QSA, então o aplicativo de pagamento não deverá ser considerado ou promovido como aceito.

Nenhum fornecedor ou terceiro poderá referir-se ao aplicativo de pagamento como “Aprovado pelo PCI” ou “Aprovado pelo PCI SSC” nem informar ou implicar de outra forma que o PCI SSC aprovou, em parte ou totalmente, qualquer aspecto do fornecedor ou de seus aplicativos de pagamento, exceto até uma determinada extensão e sujeitos aos termos e restrições expressamente definidos em um acordo por escrito com o PCI SSC ou em uma Carta de aceitação do PA-DSS. Todas as outras referências à aceitação do PCI SSC são estritamente proibidas pelo PCI SSC.

Quando concedida, uma aceitação é fornecida pelo PCI SSC para garantir determinadas características de segurança e operacionais importantes para o alcance dos objetivos do PCI SSC, mas a aceitação não inclui, sob qualquer circunstância, qualquer garantia relacionada à funcionalidade, à qualidade ou ao desempenho de qualquer produto ou serviço em particular. O PCI SSC não garante qualquer produto ou serviço fornecido por terceiros. A aceitação não inclui ou implica, sob qualquer circunstância, qualquer garantia de produto pelo PCI SSC, incluindo, sem limitações, qualquer garantia implícita de

comercialização, adequação a um fim específico ou não infração, todas expressamente renunciadas pelo PCI SSC. Todos os direitos e soluções a respeito dos produtos e serviços que foram aceitos deverão ser oferecidos pela parte envolvida em fornecer tais produtos ou serviços e não pelo PCI SSC ou pelas bandeiras.

Exceto se acordado de outra forma, por escrito, pelo PCI SSC, todas as propriedades e serviços contemplados neste documento que o PCI SSC fornece a terceiros são oferecidos “tal como estão”, "com todas as falhas” e sem nenhuma garantia de qualquer forma.

(31)

Anexo A: Elementos para carta de aceitação e lista de

aplicativos de pagamento validados pelo

PA-DSS

Fornecedor do aplicativo de pagamento

Esta entrada representa o Fornecedor do aplicativo de pagamento para o aplicativo de pagamento validado.

Identificador do aplicativo de pagamento

O Identificador do aplicativo de pagamento é utilizado pelo PCI SSC para denotar as informações relevantes que representam o aplicativo de pagamento e consistem de:

 Nome do aplicativo de pagamento.

 Número de versão do aplicativo de pagamento.

Para garantir que o uso do aplicativo de pagamento validado, é altamente recomendável que os clientes adquirentes ou seus agentes designados comprem e implantem somente os aplicativos que contenham as informações que coincidem exatamente com as informações fornecidas no Identificador do aplicativo de pagamento. Exemplo de um identificador de aplicativo de pagamento (dois componentes):

Componente Descrição

Nome do aplicativo Acme Payment 600

Número de versão do aplicativo

PCI 4.53

Número de versão do aplicativo

O Número de versão do aplicativo representa a versão específica do aplicativo revisada na avaliação do PA-DSS. Os campos que compõem o Número da versão do aplicativo podem consistir de uma combinação de caracteres alfanuméricos fixos ou variáveis.

Observação:

No PA-DSS, consulte a seção Instruções e conteúdo para relatório sob validação para obter

informações detalhadas sobre o conteúdo a incluir no ROV do PA-DSS para os métodos de versão do fornecedor.

É altamente recomendável que os clientes comprem e implantem somente esses aplicativos com o Número de versão do aplicativo, cujos caracteres alfanuméricos coincidem exatamente com o Número de versão do aplicativo mostrado na Lista de aplicativos de pagamento validados pelo PA-DSS ou a Carta de aceitação do PA-DSS do fornecedor, emitida pelo PCI SSC.

Número de aprovação

O PCI SSC atribui o Número de aprovação no momento da aceitação. Esse número será o mesmo durante toda a vida útil da listagem do aplicativo.

Notas de validação

As Notas de validação são usadas pelo PCI SSC para informar se a revisão estava de acordo com o programa do PABP da Visa ou o programa do PA-DSS do PCI SSC e para informar a versão aplicável do PABP ou PA-DSS. Consulte a tabela disponível na seção Notas de implantação para ver os exemplos.

(32)

Guia do programa PCI PA-DSS v. 1.2, Elementos para carta de aceitação Outubro de 2008

Notas de implantação

As Notas de implantação são usadas pelo PCI SSC para informar se o aplicativo de pagamento é aceitável ou não para novas implantações e estão relacionadas à data de vencimento do aplicativo de pagamento, informadas a seguir. Consulte também a tabela completa na página 22 para obter informações detalhadas.

Listagem do PCI SSC antes da expiração Listagem do PCI SSC após a expiração Notas de validação Notas de implantação Notas de validação Notas de implantação

Validada de acordo com o PABP

Aceitável para novas implantações

Validada de acordo com o PABP

Inaceitável para novas implantações

Aplicativo pré-PCI Não recomendável para

novas implantações

Aplicativo pré-PCI Inaceitável para novas implantações Validada de acordo

com o PA-DSS

Aceitável para novas implantações

Validada de acordo com o PA-DSS

Inaceitável para novas implantações

Auto-atestado para pequena alteração de versão, se aplicável

O Auto-atestado para pequena alteração de versão é utilizado, quando aplicável, para informar essas versões do aplicativo que passam pelo processo para pequenas alterações no aplicativo, listadas na seção Sem impacto nos requisitos do PA-DSS deste documento.

Data de revalidação anual

A Data de revalidação anual é utilizada pelo PCI SSC para indicar quando o Atestado de validação anual do fornecedor do software irá vencer. A Revalidação anual é parte do formulário Atestado de validação, localizado no Anexo C do PA-DSS, parte 3b.

Data de vencimento

A Data de vencimento para os aplicativos de pagamento validados pelo PA-DSS é a data em que o fornecedor deve fazer com que o aplicativo seja reavaliado em relação aos requisitos atuais do PA-DSS para manter a aceitação. A data de vencimento está relacionada às Notas de implantação,

anteriormente.

O PCI SSC irá empenhar-se para atualizar o PA-DSS em um ciclo de 24 meses, em conjunto com as atualizações ao PCI DSS. A aceitação dos aplicativos de pagamento validados pelo PA-DSS vence após três anos da data efetiva de uma atualização subseqüente dos requisitos do PA-DSS. O objetivo é uma expectativa mínima de três anos de aprovação, com exceção de ameaças graves que possam exigir alterações imediatas.

Observação:

Qualquer avaliação do PA-DSS realizada na Versão 1.1 receberá a mesma data de vencimento que as revisões feitas na Versão 1.2 do PA-DSS, de acordo com o processo de vencimento normal.

Por exemplo: PA-DSS Versão 1.1 e Versão 1.2 terão a mesma data de vencimento. Com a versão seguinte do PA-DSS (aquela após a Versão 1.2) esperada para aproximadamente outubro de 2010, as análises das Versões 1.1 e 1.2 do PA-DSS vencerão em outubro de 2013.

Não existe no momento uma data de finalização para os aplicativos de pagamento validados pelo PA-DSS que estavam na lista aprovada no momento da implantação. Os aplicativos de pagamento

implantados que possuem suas aprovações vencidas poderão continuar a ser utilizados. A programação para vencimento está associada a novas compras/implantações, não a implantações existentes.

(33)

Empresa do PA-QSA

Esta entrada informa o nome da Empresa assessora de segurança qualificada de aplicativo de pagamento que realizou a validação e determinou se o aplicativo de pagamento está em conformidade com o PA-DSS.

Tipo de aplicativo de pagamento

O Tipo de aplicativo de pagamento denota um dos seguinte itens:  Ponto de venda (POS)

 Middleware

 Dispensador de combustível automático

 Carrinho de compras

 Acordo

 Cartão não presente  Gateway

 Outro

Mercado alvo

O Mercado alvo representa um mercado para o aplicativo de pagamento, se aplicável. Por exemplo, o mercado alvo pode ser um dos seguintes:

 Varejistas

 Quiosques de estacionamentos  Postos de combustível

 Comércio eletrônico

Observação:

Este exemplo destina-se a indicar se o aplicativo de pagamento foi projetado especificamente para um determinado mercado, não para fins de vendas do fornecedor do software.

Região ou local específico para o aplicativo de pagamento, se aplicável

A região ou local específico para o aplicativo de pagamento representa os aplicativos de pagamento que são desenvolvidos e somente podem ser utilizados em regiões ou locais específicos.