um toolkit para atender os requisitos técnicos do pci dss
DESCRIPTION
Trabalho de conclusão do curso superior em Segurança da Informação - Unisinos.TRANSCRIPT
UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS
UNIDADE ACADÊMICA DE GRADUAÇÃO
GRADUAÇÃO TECNOLÓGICA EM SEGURANÇA DA INFORMAÇÃO
FÁBIO JULIANO DAPPER
OPENPCI
UM TOOLKIT PARA ATENDER OS REQUISITOS TÉCNICOS DO PCI DSS
SÃO LEOPOLDO
2009
FÁBIO JULIANO DAPPER
OPENPCI
UM TOOLKIT PARA ATENDER OS REQUISITOS TÉCNICOS DO PCI DSS
Trabalho de Conclusão de Curso apresentado como requisito parcial para obtenção do título de Tecnólogo em Segurança da Informação, pela Graduação Tecnológica em Segurança da Informação da Universidade do Vale do Rio dos Sinos - Unisinos
Orientador: Prof. Ms. Leonardo Lemes Fagundes
SÃO LEOPOLDO
2009
Para minha amada esposa Cristina, que me
ensinou o verdadeiro sentido da palavra
dedicação.
AGRADECIMENTOS
À DEUS, por me guiar em todos os momentos da minha vida.
Aos meus pais, Hilário e Maria, por terem lutado muito para permitir que eu
conseguisse estudar e progredir na vida.
Ao meu professor e orientador Leonardo Lemes Fagundes, por todo o auxílio durante
a execução deste trabalho.
Conheço pessoas de ação, que sempre serão de ação.
Vocês sabem por quê?
Porque sempre terminam aquilo que começam!
Dale Carnegie.
RESUMO
A utilização dos cartões como meio de pagamento evoluiu ao longo do tempo e
atualmente é utilizado por milhões de pessoas em todo o mundo. Mas à medida que esta
tecnologia evolui também se verifica sua utilização para a realização de fraudes no comércio
varejista e eletrônico. Para mitigar este problema, foi criado o Payment Card Industry Data
Security Standard (PCI DSS), um padrão de segurança que determina requisitos para a
proteção dos dados do portador do cartão. O atendimento dos requisitos deste padrão de
segurança pode exigir a aquisição de ferramentas que em determinados casos acarretaria em
um custo elevado para as empresas. Com base nesta constatação, este trabalho apresenta um
toolkit que contém ferramentas isentas de custo de aquisição e que pode ser utilizado para
auxiliar no atendimento dos requisitos técnicos deste padrão, assim reduzindo o custo com
licenças de ferramentas comerciais.
Palavras-Chave: PCI DSS. Toolkit. Fraudes. Cartão de crédito. Linux.
LISTA DE FIGURAS
Figura 1 - Primeira versão do cartão de crédito........................................................................ 13
Figura 2 - Cartões de crédito, loja e rede .................................................................................. 14
Figura 3 - Representação da estrutura de um cartão atual ........................................................ 17
Figura 4 - Agentes envolvidos em uma transação com cartão de crédito ................................ 19
Figura 5 - Exemplo de phishing utilizando o nome da bandeira MasterCard ......................... 22
Figura 6 - Momento em que o “chupa-cabra” é inserido no terminal do banco ....................... 23
Figura 7 - Câmera colocada junto ao material de divulgação do banco ................................... 24
Figura 8 - Tela de login do OpenPCI Toolkit ........................................................................... 43
Figura 9 - Área de trabalho do OpenPCI Toolkit ..................................................................... 43
Figura 10 - Tela parcial do instrumento para análise de aderência (SAQ) ............................... 44
Figura 11 - Exemplo do relatório de não-conformidade emitido pelo SAQ ............................ 44
Figura 12 - Informações sobre a ferramenta baseada em modo texto através do Zenity .......... 45
LISTA DE QUADROS
Quadro 1 - Comprometimento de sistemas pesquisados pelo DOJ .......................................... 25
Quadro 2 - Programas de segurança das bandeiras de cartão ................................................... 27
Quadro 3 - Dados de cartão que podem ser armazenados ........................................................ 28
Quadro 4 - Padrões do PCI Council e seu público alvo ........................................................... 29
Quadro 5 - Estrutura de requisitos do PCI DSS versão 1.2.1 ................................................... 30
Quadro 6 - Modelos de SAQ para cada categoria de empresa ................................................. 35
Quadro 7 - Níveis de classificação dos estabelecimentos comerciais na bandeira Visa .......... 36
Quadro 8 - Níveis de classificação dos prestadores de serviço na bandeira Visa .................... 36
Quadro 9 - Ferramentas para atender os requisitos técnicos do PCI DSS ................................ 50
LISTA DE TABELAS
Tabela 1 - Indicadores de crescimento dos cartões .................................................................. 15
Tabela 2 - Valores de ferramentas comerciais para atender os requisitos do PCI DSS ................. 38
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 10
2 CARTÕES DE PAGAMENTO E AS FRAUDES ............................................................ 13
2.1 Visão Geral sobre os Cartões ........................................................................................... 13
2.1.1 Dados do Portador do Cartão .......................................................................................... 15
2.2 Partes Envolvidas em uma Transação com Cartão ....................................................... 17
2.3 Fraudes .............................................................................................................................. 20
2.3.1 O Impacto Decorrente das Fraudes ................................................................................. 24
2.4 Resumo .............................................................................................................................. 25
3 PADRÃO DE SEGURANÇA DA INDÚSTRIA DE CARTÕES DE PAGAMENTO .. 27
3.1 PCI DSS ............................................................................................................................. 27
3.1.1 Estrutura de Requisitos .................................................................................................... 29
3.2 Processo de Conformidade e Penalidades ...................................................................... 34
3.2.1 Custo do Processo de Conformidade ............................................................................... 37
3.3 Resumo .............................................................................................................................. 39
4 TOOLKIT ............................................................................................................................ 40
4.1 Visão Geral do Toolkit ..................................................................................................... 40
4.2 Estrutura do Toolkit ......................................................................................................... 42
4.2.1 Ferramentas Selecionadas ............................................................................................... 46
4.3 Projetos Relacionados ...................................................................................................... 51
5 CONSIDERAÇÕES FINAIS .............................................................................................. 53
5.1 Contribuições .................................................................................................................... 54
5.2 Trabalhos Futuros ............................................................................................................ 54
REFERÊNCIAS ..................................................................................................................... 56
10
1 INTRODUÇÃO
A forma como as pessoas vêm efetuando o pagamento de produtos e serviços tem
evoluído ao longo do tempo. Algumas décadas atrás, o dinheiro em papel e o cheque eram as
únicas formas disponíveis, embora nem sempre as mais adequadas, devido ao medo das
pessoas portarem determinadas quantias de dinheiro ou por parte dos estabelecimentos
comerciais em receber algum cheque sem fundo. A conseqüente falta de dinheiro e cheque no
momento de um pagamento já se tornava um problema para quem precisava de crédito no
comércio (PARODI, 2008).
Devido a isto, foi criada uma alternativa aos meios tradicionais de pagamento que
beneficiava consumidores e estabelecimentos comerciais, onde instituições financeiras
concediam crédito que era vinculado a um cartão em nome do portador do mesmo. Através
deste cartão, o consumidor poderia realizar suas compras e efetuar o pagamento somente no
final do mês, através de uma fatura contendo o valor das compras acrescido de uma taxa de
juros definida pela instituição financeira.
A evolução do cartão como meio de pagamento atinge atualmente índices que
comprovam sua efetividade e boa aceitação no comércio varejista e eletrônico. De acordo
com dados da Associação Brasileira das Empresas de Cartões de Crédito e Serviços
(ABECS), no ano de 2008 o número de compras com cartões foi 24% superior ao ano
anterior, atingindo um faturamento de R$375,4 bilhões de reais (ABECS, 2009).
Com a expansão na utilização de cartões e devido à ocorrência de incidentes
envolvendo este meio de pagamento eletrônico, a indústria de cartões criou um padrão de
segurança conhecido como Payment Card Industry Data Security Standard (PCI DSS) que
visa criar procedimentos para a proteção dos dados do portador de cartão. Toda empresa que
armazena, processa ou transmite os dados do portador de cartão deve provar através de
auditorias que está em conformidade com todos os requisitos de segurança exigidos pelo PCI
DSS (PCI, 2008).
A criação de padrões e boas práticas de segurança podem fortalecer a efetividade e o
aumento na utilização desta tecnologia por parte de estabelecimentos comerciais e
11
consumidores. De acordo com o 2009 Data Breach Investigations Report, 81% das empresas
inseridas no mercado de cartões não estavam em conformidade com as boas práticas de
segurança e com os padrões existentes no momento em que os incidentes envolvendo os
dados de cartões ocorreram (NOVAK, 2009).
O fato de uma empresa não estar em conformidade com o PCI DSS, pode facilitar a
ocorrência de incidentes de segurança e impactar em penalidades que vão desde multas até o
descredenciamento que não permitirá mais a operação com cartões. Outro fator relevante que
deve ser considerado nestes casos é a imagem da empresa perante o seu mercado de atuação
em caso de um comprometimento dos dados do portador de cartão.
Para uma empresa atingir a conformidade com o PCI DSS, é exigido em grande parte
a implementação de controles técnicos, que podem ir desde a instalação de dispositivos de
firewall até a centralização dos eventos de segurança. Para isto, pode ser necessário
investimentos na aquisição de ferramentas de segurança e na contratação de uma consultoria
especializada para auxiliar no processo de interpretação e implementação dos controles.
Dependendo do tamanho e da infra-estrutura da empresa, o investimento em novas
tecnologias pode ser um fator crítico no processo de conformidade, visto que muitas delas
podem exigir um alto custo de aquisição e manutenção de licenças de uso (ORACLE, 2009).
Este trabalho tem como objetivo projetar e disponibilizar um toolkit com ferramentas
isentas de custo de aquisição para auxiliar as empresas no processo de conformidade com o
PCI DSS, organizando tais ferramentas de acordo com a intenção de cada requisito do padrão.
Além das ferramentas, o toolkit irá incluir um instrumento que irá auxiliar no processo de
análise de aderência com o PCI DSS. Após a execução deste instrumento, um relatório de
não-conformidade irá apontar quais ferramentas disponíveis no toolkit poderão ser utilizadas
na implementação dos controles técnicos de segurança.
Este trabalho está organizado da seguinte forma:
No capítulo 2 será apresentada uma visão geral sobre os cartões, os aspectos relativos
às fraudes envolvendo os dados do portador de cartão e os impactos decorrentes das fraudes.
O capítulo 3 irá apresentar o PCI DSS, seus requisitos e quais os passos envolvidos no
12
processo de conformidade. No capítulo 4 será apresentado o toolkit com as ferramentas
selecionadas para atender os requisitos técnicos do PCI DSS. Para finalizar, o capítulo 5 traz
as considerações finais e as sugestões para trabalhos futuros.
13
2 CARTÕES DE PAGAMENTO E AS FRAUDES
O capítulo 2 irá apresentar a origem dos cartões e sua evolução como meio de
pagamento amplamente utilizado atualmente. Os dados do portador do cartão serão
detalhados, assim como as partes envolvidas em uma operação de venda com cartão de
crédito. Ainda neste capítulo, será abordado como tais dados podem ser utilizados na
realização de fraudes e quais as conseqüências destas fraudes para os consumidores e
empresas que aceitam cartões como forma de pagamento.
2.1 Visão Geral sobre os Cartões
A utilização do cartão como meio de pagamento em diversos estabelecimentos
comerciais teve início na década de cinqüenta nos EUA através do empresário Frank
MacNamara, que ao receber a conta do restaurante, percebeu que estava sem dinheiro e talão
de cheques para efetuar o pagamento. Diante desta situação, Frank MacNamara teve que
negociar com o dono do estabelecimento para pagar a conta outro dia, desde que assinasse
uma nota de despesas.
O primeiro cartão de crédito foi emitido em 1950 pela Diners Club Inc, empresa
criada pelo próprio Frank MacNamara, que através de seu caso, concebeu a idéia do cartão de
crédito.
Figura 1 - Primeira versão do cartão de crédito Fonte: Parodi (2008).
14
A figura 1 ilustra o primeiro cartão de crédito emitido pela Diners Club Inc em 1950,
confeccionado ainda em papel. Em 1951 foi criado o primeiro cartão de crédito bancário,
através do banco Franklin National Bank, que cobrava taxas para disponibilizar o crédito aos
usuários do seu cartão. Somente em 1955 o cartão começou a ser emitido em plástico.
Com a popularização do cartão, vários estabelecimentos comerciais começaram a
aceitá-lo como meio de pagamento, sendo que em 1960 o cartão já era aceito em cinqüenta
países em todos os continentes.
O mercado atual de cartões no Brasil é dividido em quatro categorias classificadas
pela ABECS como cartão de crédito, débito, rede e loja. Cada categoria possui um mercado
de atuação que se caracteriza basicamente pelo público alvo. Um cartão de loja costuma ter
seu uso restrito para utilização em um determinado estabelecimento e é conseqüentemente
mais limitado em termos de abrangência do que um cartão de crédito com bandeira.
Tais categorias são detalhadas a seguir:
• Cartão de crédito:
� Cartão de grandes bandeiras internacionais como, Visa, MasterCard, Diners,
American Express, JCB, Discover).
• Cartão de débito:
� Cartão com acesso a contas bancárias (corrente, poupança) como, MasterCard
(Maestro e Redeshop) e Visa (Visa Electron).
• Cartão de loja:
� Cartão para uso exclusivo em uma rede varejista (C&A, Renner).
• Cartão de rede:
� Cartão aceito em rede de múltiplos estabelecimentos comerciais (Hipercard,
Goodcard).
Figura 2 - Cartões de crédito, loja e rede Fonte: Site do Itaú, C&A e Hipercard (2009).
15
A figura 2 ilustra exemplos de cartões de crédito, loja e rede, respectivamente.
Cabe ressaltar que esta divisão é classificada com base no mercado brasileiro, apesar
de existirem outras modalidades menores que não são monitoradas pela ABECS.
A evolução do cartão como meio de pagamento atinge atualmente índices que
comprovam sua efetividade e boa aceitação no comércio varejista e eletrônico. Dados recentes
da ABECS demonstram um aumento considerável a cada ano. Tais índices são impulsionados
pela emissão de novos cartões e pela oferta de crédito por parte das instituições financeiras.
Tabela 1 - Indicadores de crescimento dos cartões
Janeiro Fevereiro Março Abril Maio
Cartões - Milhões 518 521 524 531 535
Variação % ano anterior 13% 13% 12% 13% 12% Transações – Milhões 458 437 471 471 497
Variação % ano anterior 16% 14% 14% 17% 14% Faturamento - Bilhões 32,6 30,2 33,2 33,5 36
Variação % ano anterior 19% 16% 17% 20% 17%
Fonte: Adaptado de ABECS (2009).
Conforme indicado na tabela 1, é possível verificar um aumento nos cinco primeiros
meses de 2009 em relação ao mesmo período de 2008 para o número de cartões emitidos,
transações executadas com cartões e o faturamento obtido.
2.1.1 Dados do Portador do Cartão
Os cartões atuais seguem uma padronização de acordo com as normas internacionais
da ISO/IEC (7810, 7811, 7812) para questões como tipo de material, dimensão, largura,
técnicas de gravação e layout para armazenamento das informações do cartão, também
conhecidas como os dados do portador de cartão. Estas informações são utilizadas para
identificar a validade de um cartão, seu titular e para confirmar a autenticidade em uma
transação eletrônica.
A utilização destes dados é convencionada por todas as bandeiras de cartão e meios de
pagamento eletrônico durante a realização de uma transação, pois como o fluxo de dados é
16
processado por diferentes sistemas, a interoperabilidade se torna um fator fundamental
(NAKAYA, 2009).
Os dados utilizados para a identificação e autenticação de uma transação eletrônica
com cartão são apresentados conforme a seguir:
• PAN (Número do cartão):
� Número de treze, quinze ou dezesseis dígitos que identifica exclusivamente o
cartão do portador.
• Nome do portador do cartão.
• Código de serviço:
� Identifica o tipo do cartão (nacional, internacional, restrições de uso).
• Data de vencimento do cartão.
• PIN/PIN Block.
• Código de segurança (CAV2, CVC2, CVV2, CID).
A forma mais comum e ainda muito utilizada atualmente para o armazenamento destas
informações é a tarja magnética, que é encontrada no verso dos cartões, vide figura 3.
Os dados armazenados na tarja magnética são utilizados durante o processo de uma
venda presencial, onde o PDV1 realiza a validação dos dados do portador juntamente com a
administradora do cartão para aprovar a compra. Já o código de segurança de três ou quatro
dígitos é utilizado somente durante uma venda não presencial, como por exemplo, em uma
compra via Internet onde o portador original do cartão necessitará informar tal código para
comprovar que está de posse do cartão. O PIN/PIN Block (Personal Identification Number) é
a senha pessoal e intransferível do portador do cartão, utilizado em algumas operações como
saque de dinheiro em terminais de banco e compras com cartão de débito.
De acordo com PCI (2008), os dados completos da tarja magnética, código de
segurança e PIN/PIN Block, devem receber atenção especial para evitar a cópia indevida
destas informações, o que possibilitaria sua utilização em fraudes como a clonagem dos
cartões.
1 PDV ou ponto de venda é o terminal eletrônico utilizado para ler as informações contidas no cartão.
17
Figura 3 - Representação da estrutura de um cartão atual Fonte: Adaptado de PCI (2008)
A figura 3 ilustra a estrutura padrão de um cartão utilizado atualmente e seus
principais dados. A única exceção fica por conta da bandeira American Express, que
armazena o código de segurança (CID) de quatro dígitos na frente do cartão, enquanto as
demais bandeiras armazenam um código de três dígitos no verso, logo abaixo da tarja
magnética.
Apesar da tarja magnética ainda ser utilizada na grande maioria dos cartões atuais, a
utilização do chip2 tem crescido no mundo todo por trazer alguns benefícios como maior
capacidade de armazenamento e proteção dos dados do portador de cartão contra a clonagem
nos terminais de venda ou bancos.
Os aspectos relacionados à proteção e fraudes envolvendo os dados do portador do
cartão, serão apresentados na seção 2.3 deste capítulo.
2.2 Partes Envolvidas em uma Transação com Cartão
Manter uma infra-estrutura para atender qualquer tipo de comércio eletrônico pode não
ser uma tarefa muito trivial. Com a evolução da Internet e dos meios de pagamento eletrônico,
registrou-se também um aumento considerável na utilização do cartão de crédito como forma
2 Cartão inteligente com um microprocessador interno, capaz de armazenar de forma segura os dados do portador
de cartão.
18
de pagamento (CENTRO DE ESTUDOS SOBRE AS TECNOLOGIAS DA INFORMAÇÃO
E DA COMUNICAÇÃO - CETIC, 2008).
A cadeia de sistemas responsável por manter a infra-estrutura da indústria de cartões
de pagamento é composta por diferentes agentes e com diferentes papéis.
Os agentes envolvidos em uma operação com cartão de crédito, por exemplo, estão
descritos conforme a seguir (REDECARD, 2009):
• Portador do cartão:
� Indivíduo que possui um cartão com uma linha de crédito aprovada pelo banco.
• Estabelecimento comercial:
� Estabelecimento ou prestador de serviços, que aceita um cartão como meio de
pagamento.
• Bandeira de cartão:
� Constitui a marca do cartão. Define as regras do cartão e estão associadas aos
bancos.
• Emissor:
� É a instituição financeira (banco) do portador que emite, administra o cartão e
financia o crédito.
• Adquirente:
� É um membro licenciado pela bandeira, responsável pelo credenciamento e
gerenciamento entre a bandeira e o estabelecimento comercial.
• Processadoras:
� Empresas responsáveis pela parte operacional das transações, emissão de faturas
e atendimento aos estabelecimentos comerciais.
Com a exceção do portador de cartão, que é o consumidor final nesta cadeia, os
demais agentes necessitam garantir a eficácia e a segurança de seus sistemas de pagamento.
Em estabelecimentos onde o volume de transações é muito alto, a probabilidade de uma
indisponibilidade do sistema ou de um vazamento de informações pode ser muito alta.
19
O entendimento de como funciona o fluxo de uma operação com cartões é
fundamental para elaborar mecanismos de proteção que possam evitar as fraudes.
O fluxo de uma operação com cartão de crédito pode ser ilustrada conforme a figura 4,
apresentada a seguir:
Figura 4 - Agentes envolvidos em uma transação com cartão de crédito Fonte: Adaptado de Thakar (2009).
Conforme ilustrado na figura 4, uma operação com cartão de crédito tem início quando o
titular do mesmo realiza uma compra em um estabelecimento comercial. Este estabelecimento
por sua vez encaminha a solicitação de compra para o adquirente, responsável por validar
determinadas informações sobre este estabelecimento comercial e encaminhar o pedido de
autorização para a rede de pagamento da bandeira. O passo seguinte é a solicitação de
autorização de venda por parte da bandeira com o banco emissor, onde será verificada a
disponibilidade de crédito do cartão para então autorizar ou não a venda.
Em compras com o cartão de débito ou novos cartões com chip para função crédito e
débito, é solicitado ao portador do cartão à digitação da sua senha pessoal (PIN) no PDV para
efetuar a transação.
20
Este fluxo pode variar em casos onde o cartão é do tipo rede ou loja, pois a autorização
da compra pode ser efetuada diretamente na rede varejista, não sendo necessária a
participação das instituições financeiras para a aprovação do crédito.
2.3 Fraudes
Os benefícios gerados pela facilidade na utilização dos meios de pagamento eletrônico
são uma realidade presente no mundo todo. O ganho, tanto para os estabelecimentos
comerciais quanto para os consumidores é representado pelos altos índices que demonstram o
crescimento desta modalidade de pagamento.
Mas à medida que esta tecnologia vai apresentando seus benefícios, também é possível
identificar os riscos associados a ela, como o vazamento de informações e a sua utilização
para a realização de fraudes no comércio varejista e eletrônico.
Quando se relaciona o uso de cartões para a realização de compras via Internet, temos
um cenário ainda mais atrativo para o cybercrime, uma vez que a presença física no
estabelecimento não é mais necessária, podendo facilitar determinadas ações e dificultar a
descoberta da origem das fraudes.
Em casos onde o cartão de crédito foi clonado para a utilização em compras
fraudulentas, o fato pode ser desconhecido pelo portador original até que o mesmo identifique
a compra indevida em sua fatura mensal.
A responsabilidade por arcar com este custo pode gerar transtornos para o consumidor
legítimo, uma vez que o mesmo terá que comprovar perante sua administradora de cartão que
não realizou tal operação, para somente então ser reembolsado.
No Brasil, este assunto ainda está em pauta na Comissão de Constituição de Justiça e
Cidadania da Câmara dos Deputados através do projeto de lei nº 1.547/2007 que define:
21
No caso de “clonagem” de cartão de crédito, será de inteira responsabilidade da administradora os prejuízos decorrentes da utilização fraudulenta do cartão, garantindo-se ao titular o estorno imediato de todos os débitos lançados em sua fatura mensal.
Parágrafo único. Para os efeitos dessa lei, ‘clonagem’ é a obtenção fraudulenta de dados pessoais do usuário de cartão de crédito ou a cópia e transferência dos códigos da tarja magnética para um cartão falso, com a finalidade de realizar operações em nome do verdadeiro titular (BEZERRA, 2007).
Tal projeto visa proteger o consumidor legítimo de qualquer responsabilidade sobre o
uso indevido do cartão por terceiros, onde os dados foram obtidos através de meios ilícitos,
como a clonagem do mesmo. Cabe citar que nos EUA, uma lei vigente restringe a
responsabilidade do consumidor ao pagamento de no máximo $50 dólares (PERETTI, 2009).
O roubo de identidade, aqui caracterizado pela clonagem dos cartões, cópia do código
de segurança e senha pessoal possui a denominação account takeover no mercado negro de
cartões. Estas ações são executadas por grupos denominados carders que costumam utilizar
fóruns web e salas de bate-papo para vender os dados roubados. Informações que possibilitem
a reprodução completa de um cartão de crédito falsificado podem ser vendidas neste mercado
com valores aproximados a $150 dólares por cartão (PERETTI, 2009).
A ação dos carders também pode ser caracterizada no momento em que uma pessoa
tentando se passar por funcionário de uma administradora de cartão realiza a troca do PDV
legítimo por outro equipamento adulterado.
Diversos sistemas podem ser o alvo de ações dos carders em busca de informações
para a realização de fraudes. Os mais procurados, no entanto, são as redes de empresas que
processam um grande volume de transações com cartão, como as processadoras, instituições
financeiras e grandes estabelecimentos comerciais. Somente em 2007, uma única empresa
norte-americana registrou um comprometimento de 94 milhões de contas de cartão de crédito
através de uma invasão em seus sistemas (PERETTI, 2009).
Apesar de o alvo preferido ser as grandes instituições, o consumidor final também é
alvo da ação maliciosa dos carders. Através de técnicas de phishing3, os carders criam sites e
3 Mensagem não solicitada que tenta se passar por um e-mail legítimo de uma instituição conhecida e procura
induzir o usuário a fornecer informações pessoais ou financeiras.
22
mensagens falsas para tentar obter os dados confidenciais como o código de segurança do
cartão e senhas pessoais.
Figura 5 - Exemplo de phishing utilizando o nome da bandeira MasterCard Fonte: CAIS (2009)
A figura 5 ilustra um exemplo de mensagem falsa utilizada pelos carders para tentar
induzir o portador do cartão e executar um formulário, mas que se trata na verdade de um
código malicioso que é utilizado para obter dados pessoais do usuário do cartão.
Quando a utilização de técnicas como phishing não traz resultados, os grupos
especializados em capturar os dados do portador recorrem a outro método conhecido como
skimming, que consiste em substituir o terminal eletrônico por um dispositivo falso que irá
realizar a leitura dos dados contidos na tarja magnética do cartão. Este dispositivo é conhecido
23
no Brasil como “chupa-cabra” e é muito utilizado em estabelecimentos comerciais e caixas de
bancos (PARODI, 2008).
Além de realizar a cópia dos dados da tarja magnética, os carders utilizam o recurso
de câmeras de vídeo para gravar o momento em que o portador do cartão digita sua senha
pessoal no terminal. Com posse dos dados da tarja magnética e da senha pessoal, é possível
realizar compras e sacar dinheiro diretamente na conta bancária do titular.
Figura 6 - Momento em que o “chupa-cabra” é inserido no terminal do banco Fonte: Commonwealth Bank (2009).
A figura 6 ilustra o momento em que o dispositivo conhecido como “chupa-cabra” é
instalado no caixa eletrônico para a realização da cópia dos dados da tarja magnética. Após
permanecer por algum período capturando as informações, o dispositivo é retirado das
dependências do banco e os dados são utilizados para clonar os cartões.
24
Figura 7 - Câmera colocada junto ao material de divulgação do banco Fonte: Commonwealth Bank (2009).
O processo seguinte para completar a fraude é gravar o momento exato em que o
portador do cartão digita sua senha no terminal eletrônico. Esta ação é realizada através de
câmeras de filmagem instaladas próximo ao terminal, conforme ilustrado na figura 7.
2.3.1 O Impacto Decorrente das Fraudes
A utilização de uma determinada tecnologia na realização de fraudes é um evento que
pode trazer conseqüências negativas tanto para o consumidor final quanto para as empresas
prestadoras de serviços da indústria de cartões de pagamento.
No caso das fraudes envolvendo cartões de crédito e débito, as conseqüências são
caracterizadas por atos ilícitos como o roubo de dinheiro das contas bancárias e a realização
de compras fraudulentas em nome do portador original do cartão. Para as empresas afetadas
com tais comprometimentos, a imagem perante seu mercado de atuação e as multas impostas
pelas bandeiras de cartão podem ser considerados fatores críticos de sobrevivência (VISA,
2009).
As principais bandeiras de cartão de crédito prevêem em seus programas de segurança
multas que podem variar em cada região que atuam. A bandeira Visa através de seu programa
de segurança conhecido como Cardholder Information Security Program (CISP) chega a
25
aplicar multas de até $500 mil dólares por incidente de segurança. Já a bandeira Mastercard
aplica além dos $500 mil dólares, uma multa de $25 dólares por cartão comprometido em seu
programa de segurança Site Data Protection (SDP).
Uma vez que os métodos utilizados pelos fraudadores foram apresentados na seção 2.3
deste capítulo, é possível relacionar tais fraudes com alguns casos de comprometimento dos
dados do portador do cartão.
Alguns destes comprometimentos foram relatados em uma pesquisa do Departamento
de Justiça dos EUA (DOJ) e são apresentados conforme a seguir:
Empresa Área de atuação Comprometimento Ano CardSystem Processadora de transações
eletrônicas 239 mil cartões de crédito e débito 2005
TJX Rede de comércio 94 milhões de cartões de crédito e débito 2007
Hannaford Rede de supermercados 4.2 milhões de cartões de crédito e débito 2008
RBS WordPay
Processadora de transações eletrônicas
1.5 milhões de cartões de crédito 2008
Heartland Processadora de transações eletrônicas
130 milhões de cartões de crédito e débito 2009
Network Solutions
Processadora de transações eletrônicas
573.928 mil cartões de crédito 2009
Quadro 1 - Comprometimento de sistemas pesquisados pelo DOJ Fonte: Adaptado de Peretti (2009).
O quadro 1 demonstra que nos últimos cinco anos várias empresas foram alvo da ação
de criminosos a procura de dados de cartões para a realização de fraudes. Cabe ressaltar que
não existe um órgão regulatório público que registre os incidentes e comunique as partes
envolvidas após o comprometimento de cartões. Tais incidentes costumam ser divulgados
pelas próprias empresas afetadas, como forma de mostrar transparência na condução e
resolução do problema para seu público alvo.
2.4 Resumo
Neste capítulo apresentou-se a origem do cartão como meio de pagamento e a
evolução da sua utilização nos últimos anos. Os dados do portador do cartão utilizados para
autorizar uma venda foram detalhados, assim como todas as partes envolvidas em uma
26
transação eletrônica com cartão. Uma vez apresentado os dados do portador do cartão e as
partes envolvidas em uma transação eletrônica, foi possível abordar um assunto de extrema
importância que são as fraudes neste meio de pagamento e suas conseqüências.
27
3 PADRÃO DE SEGURANÇA DA INDÚSTRIA DE CARTÕES DE PAGAMENTO
Com a ocorrência das fraudes e o elevado número de cartões comprometidos em
diversas empresas, foram necessários diversos esforços da indústria de cartões para criar
mecanismos de proteção para os dados do portador do cartão. Este capítulo irá abordar o
padrão de segurança criado pelas bandeiras de cartão (PCI DSS) e todo o processo envolvido
para que as empresas demonstrem conformidade com ele.
Ao decorrer deste capítulo, apresenta-se de forma mais detalhada a estrutura de
requisitos do PCI DSS, suas origens, as atividades envolvidas durante o processo de
conformidade e as penalidades impostas pelas bandeiras de cartão de crédito. Ainda neste
capítulo, será apresentada uma amostragem do custo de ferramentas comerciais para atender
alguns requisitos técnicos do PCI DSS.
3.1 PCI DSS
A criação de um padrão de segurança com foco específico no mercado de cartões de
pagamento surgiu devido à preocupação das grandes bandeiras de cartão em criar mecanismos
de proteção para evitar as fraudes envolvendo os dados do portador do cartão.
Inicialmente, as bandeiras de cartão mantinham seus próprios programas de segurança,
com ações que não eram integradas entre si. Devido a esta falta de integração, diversos
estabelecimentos comerciais necessitavam comprovar conformidade com requisitos que
divergiam de uma bandeira para outra (VIRTUE, 2009).
Bandeira de Cartão Programa de Segurança Visa USA Cardholder Information Security Program (CISP)
Visa Europa Account Information Security (AIS)
MasterCard Site Data Protection (SDP)
American Express Data Security Operating Policy (DSOP)
Discover Discover Information Security & Compliance (DISC)
JCB Data Security Program (DSP)
Quadro 2 - Programas de segurança das bandeiras de cartão Fonte: Elaborado pelo autor.
28
Conforme apresentado no quadro 2, cada bandeira de cartão mantém seu próprio
programa de segurança que atualmente é utilizado para promover a adoção do PCI DSS em
seus clientes e também outras ações contra a ocorrência de fraudes.
Devido algumas incompatibilidades entre os programas de segurança, as bandeiras de
cartão de crédito Visa e MasterCard reuniram esforços e criaram o Payment Card Industry
Data Security Standard (PCI DSS).
O PCI DSS define os requisitos de segurança que todas as empresas que processam,
transmitem ou armazenam os dados do portador do cartão devem adotar para reduzir a
possibilidade de fraudes envolvendo tais dados. Além dos requisitos, existe uma definição
sobre quais dados podem ou não ser armazenados, mesmo que aplicados todos os controles
previstos pelo PCI DSS.
Dados gerais Armazenamento permitido
Dados do portador do
cartão
Número do cartão Sim
Nome do portador do cartão Sim
Código de serviço Sim
Data de vencimento Sim
Dados de autenticação
confidenciais
Dados completos da tarja magnética Não
CAV2/CVC2/CVV2/CID Não
PIN/PIN Block Não
Quadro 3 - Dados de cartão que podem ser armazenados Fonte: Adaptado de PCI (2008).
Conforme ilustrado no quadro 3, os dados que não podem ser armazenados, mesmo se
protegidos, estão relacionados ao processo de autenticação de uma transação com cartão,
como o código de segurança, PIN/PIN Block e os dados completos da tarja magnética, uma
vez que podem ser utilizados na clonagem dos cartões e posteriormente na realização de
fraudes.
Em 2006, o controle e a manutenção do PCI DSS passaram a ser realizados através de
um conselho mundial chamado de PCI Security Standards Council (PCI SSC) que é
constituído pelas maiores bandeiras de cartão de crédito (Visa, MasterCard, American
29
Express, Discover Network e JCB). O PCI Council mantém um ciclo de vida de dois anos
para cada versão do PCI DSS, que atualmente se encontra na versão 1.2.1.
O PCI Council mantém além do PCI DSS, outros dois padrões. Um deles é voltado para
a segurança dos terminais eletrônicos e foi nomeado como PIN Entry Devices (PED) enquanto
o outro é direcionado para a segurança das aplicações que manipulam os dados do portador do
cartão, conhecido como Payment Application Data Security Standard (PA-DSS).
Aderência aos padrões do PCI Council
PCI PED (PIN Entry Devices) PCI PA-DSS (Payment Application
Data Security Standard)
PCI DSS (Data Security
Standard)
Fabricantes de Hardware Fabricantes de Software Comerciantes e Processadoras
Quadro 4 - Padrões do PCI Council e seu público alvo Fonte: Adaptado de PCI (2008).
O quadro 4 demonstra a quem se destinam os padrões de segurança criados e mantidos
pelo PCI Council. O PCI DSS foi criado para todas as empresas que processam, transmitem e
armazenam os dados do portador do cartão, sendo também o único padrão a ser detalhado
neste capítulo.
Embora o PCI DSS seja uma obrigação imposta apenas pelas bandeiras de cartão, o
estado norte-americano de Nevada já o transformou em uma lei como a Sarbanes-Oxley
(WIENER, 2009). Não há registro de leis equivalentes em outros países e cabe ressaltar que
cada bandeira é responsável por definir as datas limites para que as empresas estejam em
conformidade com o PCI DSS.
3.1.1 Estrutura de Requisitos
A estrutura do PCI DSS é constituída por seis grupos lógicos que definem doze
requisitos de segurança. Estes doze requisitos por sua vez, contemplam diversas exigências
que somadas chegam a mais de duzentos controles na última versão do PCI DSS.
30
É possível identificar que diversos controles disponíveis no PCI DSS já são
contemplados em outras normas de segurança como a ISO/IEC 27001 e ISO/IEC 27002. A
diferença principal é que os controles descritos no PCI DSS tem como foco principal o
ambiente onde os dados de cartão são manipulados, enquanto as normas citadas se aplicam a
qualquer ambiente, independente do mercado de atuação da empresa.
Embora a maioria dos controles possua aspectos técnicos, outros são concentrados em
ações como gerenciamento de risco e a manutenção de uma política de segurança, fazendo
com que exista a necessidade de criação ou revisão dos processos e documentações nas
empresas (THAKAR, 2009).
A estrutura de requisitos do PCI DSS é ilustrada conforme o quadro 5, apresentado a
seguir:
Quadro 5 - Estrutura de requisitos do PCI DSS versão 1.2.1 Fonte: PCI (2008).
O quadro 5 apresenta os seis grupos lógicos e os doze requisitos de segurança exigidos
pelo PCI DSS para combater as fraudes envolvendo os dados do portador do cartão. Tais
grupos e requisitos, assim como a sua intenção estão descritos a seguir:
31
• Construa e mantenha uma rede segura:
� Requisito 1:
� O primeiro requisito do PCI DSS está relacionado ao gerenciamento de uma
configuração de firewall que permita isolar o ambiente de dados do portador
de cartão dos demais ativos da empresa. Tal controle tem como objetivo
evitar o acesso indevido originado tanto da rede pública, quanto da rede
interna ao ambiente que processa os dados de cartões. Além disso, é
necessário manter um desenho atualizado com a topologia atual da rede.
� Requisito 2:
� Alterar a senhas e configurações padrões de fábrica costuma ser uma boa
prática para evitar a exploração de contas administrativas através de senhas
conhecidas publicamente.
• Proteger os dados do portador do cartão:
� Requisito 3:
� Proteger os dados do portador de cartão armazenados consiste em utilizar
mecanismos de criptografia como algoritmos de hash (ex: MD5, SHA-1),
criptografia de chave simétrica (ex: DES, AES) ou assimétrica (ex: RSA,
ECC). Além disso, é necessário criar procedimentos para o correto
gerenciamento das chaves criptográficas. O PCI DSS recomenda que só se
armazene os dados do portador de cartão, caso seja um requisito de negócio.
� Requisito 4:
� Caso os dados do portador de cartão sejam transmitidos via rede pública, os
mesmos devem ser protegidos através de mecanismos de segurança como
Redes Virtuais Privadas (VPN). A utilização de redes sem fio (wireless),
também devem receber a devida proteção, através da utilização de padrões
como o 802.11i, muitas vezes chamado de WPA2.
32
• Manter um programa de gerenciamento de vulnerabilidades:
� Requisito 5:
� É necessário manter o software de antivírus sempre atualizado para os
sistemas que funcionam na plataforma Microsoft. O sistema de antivírus deve
ser capaz de detectar além de vírus, qualquer outro tipo de código malicioso,
como spyware e trojans, por exemplo.
� Requisito 6:
� O requisito 6 trata da necessidade de se aplicar todas as correções de
segurança disponibilizadas pelas fabricantes de software em até no máximo
um mês após o seu lançamento. Outro assunto coberto pelo requisito 6 é a
segurança no desenvolvimento de aplicações para uso dentro da própria
empresa. Neste caso é exigido a implementação de um sistema para
gerenciamento de mudanças e a utilização das boas práticas do Open Web
Application Security Project Guide (OWASP).
• Implementar medidas de controle de acesso rigorosas:
� Requisito 7:
� A intenção do requisito 7 é de prover acesso aos dados do portador do cartão
somente para as pessoas cuja função exija acesso a tais dados. O
estabelecimento da segregação de funções com privilégios mínimos é
fortemente recomendado para evitar acesso indevido aos dados de cartão.
� Requisito 8:
� A atribuição de uma identificação única para cada pessoa que tenha acesso
aos sistemas ou dados de cartão é o princípio básico do requisito 8. Além
disso, o requisito 8 exige que se definam ações para uma correta
administração das contas e senhas dos usuários, como a remoção de contas
inativas, troca de senhas pelo menos a cada noventa dias, bloqueio de
terminais com sessões inativas a mais de quinze minutos e a utilização de
autenticação de dois fatores (senha e certificados digitais) para conexões
remotas.
33
� Requisito 9:
� O requisito 9 prevê ações para o controle de acesso físico ao ambiente dos
dados do portador do cartão, através de medidas como a utilização de
câmeras de vídeo, identificação diferenciada entre colaboradores e terceiros e
procedimentos para retenção e destruição de mídias de backup.
• Monitorar e testar as redes regularmente:
� Requisito 10:
� O registro de logs é um item importante para a detecção dos incidentes de
segurança. O requisito 10 exige que todos os sistemas que manipulam dados
de cartões, assim como o ambiente conectado a tais dados, registrem eventos
como identificação do usuário, origem do acesso, data e horário do acesso.
Outros tópicos como sincronização do relógio dos sistemas e a centralização
dos logs em um servidor são previstos neste requisito.
� Requisito 11:
� O requisito 11 trata dos testes de segurança que devem ser executados
periodicamente para verificar o nível de segurança da rede que processa
dados de cartões. Neste requisito estão previstos procedimentos como a
verificação de redes sem fio instaladas, realização de análise de
vulnerabilidade, testes de penetração, utilização de sistemas de detecção de
intrusão e manter a integridade de arquivos críticos.
• Manter uma política de segurança da informação:
� Requisito 12:
� O requisito 12 é um dos únicos que não especificam requisitos técnicos de
controle, possuindo como foco a criação e manutenção de uma política de
segurança voltada para o ambiente dos dados do portador do cartão. Tal
política deve contemplar ações tanto para colaboradores como para terceiros.
Entre as principais atividades, está a necessidade de se criar uma estrutura
para gerenciamento de risco e incidentes de segurança.
34
3.2 Processo de Conformidade e Penalidades
Uma vez apresentado os requisitos do PCI DSS e suas intenções, é possível avaliar
quais esforços as empresas deverão empregar para comprovar que estão aderentes as
exigências impostas pelo padrão.
Uma recomendação importante e sugerida pelo PCI DSS é a separação do ambiente
dos dados do portador do cartão dos demais ativos da empresa, uma vez que este
procedimento pode reduzir o escopo de avaliação e o esforço necessário para implementar os
controles exigidos. O ambiente dos dados do portador do cartão é definido pelo PCI DSS
como qualquer componente de rede, servidor ou aplicativo que processe os dados de cartão ou
esteja conectado a este ambiente, como por exemplo, firewalls, banco de dados e DNS.
Caso a empresa não consiga atender de forma explícita algum controle exigido pelo
PCI DSS, ela ainda poderá fazer uso de controles compensatórios para mitigar o risco
associado ao ambiente de cartão. Para tal, os controles compensatórios deverão atender
critérios como:
• Atender a intenção original do requisito;
• Fornecer um nível de proteção igual ou superior do que o controle original.
Um exemplo de controle compensatório é a utilização do comando sudo em servidores
Unix, onde não é possível identificar quem executou alguma atividade através de uma conta
root compartilhada. Com o comando sudo, todas as tarefas administrativas serão registradas
em nome do usuário que executou a atividade, eliminando assim a necessidade de
compartilhamento da conta root que é proibido pelo requisito 8 do PCI DSS.
Já o processo de conformidade com o PCI DSS poderá ser conduzido por qualquer
profissional que consiga entender a intenção dos requisitos, mas o PCI Council mantém uma
lista de empresas certificadas para prestar consultoria durante este processo.
A fase inicial de verificação do nível de conformidade de uma empresa perante os
requisitos do PCI DSS (Gap Analysis) poderá ser realizada por consultorias denominadas
35
como Qualified Security Assessor (QSA), que possuem profissionais treinados e certificados
pelo próprio PCI Council. Já durante o atendimento de alguns requisitos como os testes de
penetração e análise de vulnerabilidades, um Approved Scanning Vendor (ASV) poderá ser
contratado, sendo que o mesmo também é certificado pelo PCI Council.
Caso a empresa opte por não contratar uma consultoria especializada, poderá utilizar
um documento mantido pelo PCI Council conhecido como Self-Assessment Questionnaire
(SAQ), que permitirá validar quais requisitos ainda não são atendidos. O PCI Council utiliza
cinco categorias de validação e quatro modelos de SAQ, apresentados conforme a seguir:
Categoria de Validação do SAQ
Descrição Modelo de
SAQ
1
Estabelecimentos do tipo cartão não-presente (comércio eletrônico ou transações por correio/telefone), todas as funções dos dados do portador do cartão são terceirizadas. Esta categoria nunca se aplica a estabelecimentos com vendas presenciais.
A
2 Estabelecimentos com máquina de carbono, sem retenção eletrônica dos dados do portador do cartão.
B
3 Estabelecimentos de terminal de discagem independente, sem retenção eletrônica dos dados do portador do cartão.
B
4 Estabelecimentos com sistemas de PDV conectados à Internet, sem retenção eletrônica dos dados do portador do cartão.
C
5 Todos os outros estabelecimentos (não incluídos nas descrições dos SAQ A-C acima) e todos os prestadores de serviço definidos por uma bandeira como qualificados para preencherem um SAQ.
D
Quadro 6 - Modelos de SAQ para cada categoria de empresa Fonte: Adaptado de PCI (2008).
O quadro 6 apresenta as categorias de validação definidas pelo PCI Council e qual
modelo de SAQ poderá ser utilizado, tanto no processo de verificação dos requisitos (Gap
Analysis), como para atender requisitos de auditorias das bandeiras de cartão.
Ao finalizar o processo de atendimento dos requisitos, o passo seguinte são as
auditorias executadas pelas bandeiras de cartão, onde as empresas terão que comprovar a
conformidade com o PCI DSS. Tais auditorias são realizadas com base em uma classificação
de níveis para cada estabelecimento comercial e empresa prestadora de serviço, sendo que
cada bandeira pode possuir níveis diferentes de classificação.
Os níveis de classificação estão baseados no volume de transações com cartão em um
período de doze meses, sendo que para cada nível, alguns requisitos de auditoria são exigidos.
36
Os quadros 7 e 8, apresentados a seguir, demonstram essa classificação conforme estipulado
pela bandeira de cartão Visa:
Estabelecimentos Comerciais (Merchant)
Nível Volume de transações Requisitos de auditoria
1 Mais de 6 milhões de transações.
Relatório de conformidade anual emitido por um QSA.
Análise trimestral da rede, executado por um ASV.
Formulário de atestado de conformidade emitido pelo
adquirente.
2 Entre 1 e 6 milhões de transações.
Emissão de um Self-Assessment Questionnaire (SAQ) anualmente.
Análise trimestral da rede, executado por um ASV.
Formulário de atestado de conformidade emitido pelo
adquirente.
3 Entre 20 mil e 1 milhão de transações (e-commerce).
Emissão de um Self-Assessment Questionnaire (SAQ) anualmente.
Análise trimestral da rede, executado por um ASV.
Formulário de atestado de conformidade emitido pelo adquirente.
4 Menos de 20 mil transações (e-commerce).
Recomendado a emissão de um Self-Assessment Questionnaire (SAQ).
Análise trimestral da rede, executado por um ASV (se aplicável ao ambiente).
Outros requisitos de auditoria definidos pelo adquirente.
Quadro 7 - Níveis de classificação dos estabelecimentos comerciais na bandeira Visa Fonte: Adaptado de Visa (2009).
Prestadores de serviço (Service Providers)
Nível Volume de transações Requisitos de auditoria
1 Mais de 300 mil transações. Análise de segurança On-Site por um QSA.
Análise trimestral da rede, executado por um ASV.
2 Menos de 300 mil transações por ano.
Emissão de um SAQ anualmente.
Análise trimestral da rede, executado por um ASV.
Quadro 8 - Níveis de classificação dos prestadores de serviço na bandeira Visa Fonte: Adaptado de Visa (2009).
Conforme apresentado nos quadros 7 e 8, as auditorias são realizadas conforme o nível
de classificação do estabelecimento comercial e do prestador de serviço em relação ao volume
37
de transações processadas. O nível 1 é o único a exigir que a avaliação seja realizada por um
QSA e um ASV. Os demais níveis não necessitam passar por uma avaliação de um QSA,
embora continuem sendo avaliados por um ASV.
As bandeiras também são as responsáveis por aplicar as penalidades pelo não
atendimento ao PCI DSS em caso de algum comprometimento dos dados do portador do
cartão. Tais penalidades costumam estar relacionadas a multas financeiras e podem chegar até
o descredenciamento da empresa.
Conforme visto no capítulo 2, o programa de segurança da bandeira Visa (CISP)
define que em caso de comprometimento dos dados do portador do cartão, as empresas podem
sofrer multas de até $500 mil dólares. Além da multa imposta pela bandeira de cartão, as
empresas podem estar sujeitas a outras penalidades previstas em leis locais.
3.2.1 Custo do Processo de Conformidade
Os investimentos envolvidos em um processo de adequação a qualquer tipo de
regulamentação ou padrão de segurança pode variar em cada empresa, uma vez que fatores
como a infra-estrutura existente, número de transações com cartões processadas e a
maturidade dos processos internos podem influenciar diretamente nesta questão.
Como a grande maioria dos controles previstos no escopo do PCI DSS possui aspectos
técnicos, a procura por ferramentas de segurança pode ser uma necessidade a ser atendida
durante o processo de conformidade.
O PCI DSS não define como as empresas devem realizar tais investimentos, deixando
sob responsabilidade da própria empresa a decisão de como direcionar seu orçamento.
A escolha por determinadas ferramentas, sejam elas comerciais ou não, pode impactar
diretamente no custo final do processo de conformidade com o PCI DSS, uma vez que
ferramentas comerciais costumam manter uma política de renovações de licenças dentro de
um determinado período.
38
Estudos do Gartner, um instituto de pesquisa voltado para a tecnologia da informação,
estima que no ano de 2007 os estabelecimentos comerciais classificados como nível 1 pelas
bandeiras de cartão investiram $568 mil dólares somente para atender os requisitos do PCI
DSS, enquanto os estabelecimentos classificados como nível 2 e 3 investiram $267 e $81 mil
dólares, respectivamente. Além do custo relacionado ao atendimento dos requisitos, foram
necessários outros investimentos como análise do ambiente que processa os dados do portador
do cartão e análises de vulnerabilidade (JOHNSON, 2008).
A tabela 2 apresentada a seguir, descreve algumas ferramentas comerciais que podem
ser utilizadas para atender determinados requisitos do PCI DSS, cuja intenção seja a
implementação de controles técnicos de segurança. Através desta tabela, é possível obter uma
visão geral sobre o custo envolvido na aquisição de tais ferramentas.
Tabela 2 - Valores de ferramentas comerciais para atender os requisitos do PCI DSS
Ferramenta Fabricante Custo aproximado em
dólar Requisito do
PCI DSS Power-1 Security Appliances
5070 Checkpoint $36.500 1, 4
Barracuda Web Application Firewall 660
Barracuda Networks $17.000 6
Oracle Identity Management
Oracle $270.000 8
RSA EnVision
RSA $160.000 10
Retina Network Security Scanner
eEye Digital Security
$1.650 11
Fonte: Elaborado pelo autor.
Os valores apresentados na tabela 2 estão baseados em preços adquiridos diretamente
no site dos fabricantes, portanto não representam o custo total do investimento. Outras
questões como serviços de instalação, suporte e renovação de licenças também devem ser
consideradas. Além do investimento em ferramentas de segurança, as empresas devem
planejar qual o custo envolvido para manter sua estrutura aderente ao PCI DSS, à medida que
novos ativos venham a ser incluídos no ambiente dos dados do portador do cartão, podendo
acarretar em novos investimentos.
39
3.3 Resumo
Conforme visto neste capítulo, o PCI DSS foi criado com o intuito de prover
mecanismos para proteger os dados do portador do cartão contra as fraudes. Atualmente o PCI
DSS é mantido por um conselho mundial que define quais são os requisitos que as empresas
que processam, armazenam ou transmitem os dados do portador do cartão devem implementar
em seus ambientes. O processo de conformidade com o PCI DSS pode ser acompanhado por
empresas certificadas pelo próprio PCI Council, conhecidas como QSA e ASV.
Cada empresa é classificada perante o PCI DSS de acordo o volume de transações com
cartões que executa e é através desta classificação que será definido como serão realizadas as
auditorias nestas empresas. O custo para atender todos os requisitos do PCI DSS pode variar
entre cada empresa, pois será necessário avaliar a necessidade de adquirir novas ferramentas
de segurança ou até mesmo a contratação de alguma consultoria especializada.
40
4 TOOLKIT
O capítulo 3 apresentou o padrão de segurança da indústria de cartões de pagamento
criado pelas maiores bandeiras de cartão do mundo e mantido atualmente por um conselho
mundial conhecido como PCI Council. Também foram descritas quais são as atividades
envolvidas durante o processo de conformidade.
Através dos valores apresentados na tabela 2 do capítulo anterior, é possível verificar
que o custo para adquirir e manter ferramentas pode se tornar um dos fatores mais
preocupantes para uma empresa durante e após o processo de conformidade com o PCI DSS,
pois nem sempre as mesmas dispõem de orçamento apropriado. Com base nestas
informações, nota-se que a redução de custo para se adequar as exigências do PCI DSS se
torna um grande desafio para as empresas que manipulam dados de cartão, como
estabelecimentos comerciais e prestadores de serviço.
4.1 Visão Geral do Toolkit
A proposta deste trabalho é projetar e disponibilizar um toolkit que contenha
ferramentas isentas de custo de aquisição para auxiliar no processo de atendimento dos
requisitos técnicos do PCI DSS.
O conceito de um toolkit remete a idéia de um conjunto de ferramentas que possui um
propósito específico e que poderá ser utilizado para atender uma determinada atividade, como
um projeto, por exemplo (GOOGLE CODE, 2009).
Entre as diversas iniciativas disponíveis atualmente que disponibilizam toolkits,
podemos citar:
• Google Web Toolkit: Fornece ferramentas que visam facilitar o
desenvolvimento de aplicações web utilizando Ajax4 (GOOGLE CODE, 2009).
4 Utilização de tecnologias como Javascript e XML para desenvolver aplicações web.
41
• Network Security Toolkit (NST): Live CD/DVD baseado na distribuição
GNU/Linux Fedora que reúne diversas ferramentas de segurança Open Source
(NST, 2009).
• Solaris Security Toolkit: Fornece ferramentas para aumentar a segurança do
sistema operacional Solaris, desenvolvido pela empresa Sun Microsystems
(SUN, 2009).
• IBM Migration Toolkit: Fornece ferramentas para migrar informações
armazenadas em banco de dados como Oracle, Sybase e Microsoft SQL Server
para o seu produto, conhecido como DB2 (IBM, 2009).
• FDTK-UbuntuBR: Distribuição GNU/Linux para coleta e análise de dados em
Perícias de Forense Computacional (NEUKAMP, 2009).
O toolkit proposto neste trabalho foi nomeado como OpenPCI, por considerar que sua
utilização é aberta para qualquer empresa que necessite atender as exigências do PCI DSS,
ficando livres de qualquer custo para sua utilização e atualização.
A construção do OpenPCI Toolkit está baseada em uma distribuição GNU/Linux. A
escolha por uma distribuição GNU/Linux se deve ao fato de ser um sistema operacional
amplamente utilizado atualmente e por conter diversas ferramentas voltadas para segurança.
O sistema base para a criação do toolkit é a distribuição Ubuntu versão servidor, por ser
focado no mercado corporativo e possuir características voltadas à segurança, como serviços
de rede e a conta do super usuário root desabilitados após a instalação.
Além das características citadas anteriormente, a distribuição Ubuntu versão servidor
garante as atualizações de segurança e suporte que podem chegar até cinco anos, trazendo
assim um grande benefício para ambientes corporativos.
As ferramentas incluídas no toolkit podem possuir diferentes tipos de licença de uso,
mas geralmente costumam ser distribuídas através de licenças como a General Public License
(GPL) e a Berkeley Software Distribution (BSD). Cabe ressaltar que o toolkit não se limita a
utilizar apenas ferramentas regidas sob estas duas licenças, desde que o princípio fundamental
do toolkit seja mantido, que é a utilização somente de ferramentas isentas de custo para
aquisição e manutenção de licenças.
42
Outro critério utilizado para a seleção das ferramentas é atender a intenção de cada
requisito técnico do PCI DSS. A intenção de cada requisito foi analisada através da leitura e
interpretação dos documentos oficiais disponibilizados pelo PCI Council. Em relação à
intenção de um requisito, pode-se citar a utilização do software Dia para atender o requisito
1.1.2, que exige a criação de diagramas de rede que identifiquem as conexões com o ambiente
dos dados do portador de cartão.
Além das ferramentas, o toolkit disponibiliza um instrumento para análise de aderência
com o PCI DSS, desenvolvido com base no Self-Assessment Questionnaire (SAQ D) apresentado
no capítulo anterior e que ao ser executado, emitirá um relatório indicando quais ferramentas
disponíveis no toolkit poderão ser utilizadas para atender os requisitos não-conforme.
Devido ao fato do sistema operacional GNU/Linux ser baseado em modo texto,
utilizou-se uma interface gráfica para facilitar a visualização das ferramentas por parte do
usuário. A interface gráfica escolhida para o toolkit foi o gnome, por se tratar da interface
padrão da distribuição Ubuntu.
Já para as ferramentas selecionadas que não possuem uma interface gráfica para
configuração e também para o desenvolvimento do instrumento para análise de aderência,
utilizou-se a ferramenta Zenity que permite criar telas gráficas para programas desenvolvidos
em Shell Script (ZENITY, 2009). A escolha do Zenity e do Shell Script deve-se ao fato de
serem suportados nativamente na distribuição Ubuntu, facilitando a criação dos scripts e por
não exigirem muitos recursos de memória e espaço em disco.
4.2 Estrutura do Toolkit
A estrutura principal do toolkit está organizada através de menus que correspondem a
cada um dos doze requisitos do PCI DSS. Cada menu poderá contemplar mais do que uma
ferramenta, visto que os requisitos podem exigir controles distintos.
Conforme descrito anteriormente, a apresentação dos menus do toolkit ao usuário é
realizada através de uma interface gráfica disponível na própria distribuição Ubuntu, conhecida
43
como gnome. A interface gráfica visa facilitar a visualização das ferramentas contidas no toolkit
e também por ser pré-requisito para o funcionamento de algumas destas ferramentas.
Figura 8 - Tela de login do OpenPCI Toolkit Fonte: Elaborado pelo autor.
A figura 8 ilustra a tela inicial de login, onde, após o usuário se autenticar, poderá ter
acesso a área de trabalho e ferramentas do OpenPCI Toolkit.
Figura 9 - Área de trabalho do OpenPCI Toolkit Fonte: Elaborado pelo autor.
44
A figura 9 ilustra a área de trabalho do OpenPCI Toolkit disponível para o usuário,
onde será possível ter acesso ao instrumento para análise de aderência (SAQ) com o PCI DSS
e as ferramentas que poderão ser utilizadas.
Após o usuário acessar a interface principal do toolkit, será possível executar o
instrumento para análise de aderência (SAQ), onde o usuário irá selecionar os requisitos do PCI
DSS que ainda não são atendidos. Ao finalizar a execução do SAQ, um relatório será emitido,
informando quais ferramentas disponíveis no toolkit poderão ser utilizadas, vide figura 11.
Figura 10 - Tela parcial do instrumento para análise de aderência (SAQ) Fonte: Elaborado pelo autor.
Figura 11 - Exemplo do relatório de não-conformidade emitido pelo SAQ Fonte: Elaborado pelo autor.
45
As figuras 10 e 11 ilustram a tela parcial do instrumento para análise de aderência
(SAQ) e do relatório de não-conformidade emitido pelo SAQ, respectivamente.
O SAQ contempla todos os requisitos exigidos pelo PCI DSS, sendo que no total, são
apresentados duzentos e nove requisitos para que o usuário possa selecionar os que ainda não
são atendidos. Ao finalizar a execução do SAQ, o relatório de não-conformidade apresenta os
requisitos selecionados pelo usuário, informando também a ferramenta indicada para
utilização e sua localização no toolkit.
Como o toolkit é baseado no sistema operacional GNU/Linux, algumas ferramentas
podem não possuir uma interface gráfica para configuração. Neste caso, quando o usuário
selecionar a ferramenta que funciona apenas em modo texto, será apresentada uma interface
gráfica desenvolvida com a ferramenta Zenity, que irá fornecer informações básicas sobre o
seu funcionamento e configuração, conforme ilustrado na figura 12.
Figura 12 - Informações sobre a ferramenta baseada em modo texto através do Zenity Fonte: Elaborado pelo autor.
Mesmo com diversas ferramentas instaladas no toolkit, é importante salientar que a
implementação dos controles por parte das empresas deve receber atenção especial para o
requisito 2.2.1 do PCI DSS que exige a utilização de uma única função para cada servidor, ou
seja, não é permitido ter serviços de firewall e VPN sendo executados em um mesmo
servidor, por exemplo.
46
4.2.1 Ferramentas Selecionadas
Conforme descrito anteriormente, a seleção das ferramentas incluídas no toolkit teve
como critérios serem isentas de custo de aquisição e atender a intenção dos requisitos técnicos
do PCI DSS.
Esta seção apresenta um quadro onde consta os requisitos técnicos do PCI DSS
atendidos pelo OpenPCI Toolkit, uma breve descrição sobre tal requisito, a ferramenta
indicada para utilização e como ela pode atender o requisito em caso de não-conformidade.
Requisito Descrição do requisito Ferramenta Utilização
1.1.2
Diagrama da rede atual com todas as conexões com relação aos dados do portador do cartão, incluindo quaisquer redes sem fio.
Dia
O software Dia permite criar diagramas da rede, identificando todas as conexões com o ambiente dos dados do portador do cartão.
1.2
Elaborar uma configuração do firewall que restrinja as conexões entre redes não confiáveis e quaisquer componentes do sistema no ambiente de dados do portador do cartão.
Iptables Firewall Builder
O iptables é a ferramenta que permite criar e administrar as regras de firewall e NAT na versão 2.6 do kernel Linux. Através dele, é possível isolar a rede que processa os dados do portador do cartão das demais redes. O Firewall Builder permite administrar estas regras através de uma interface gráfica.
1.2.1 Restringir o tráfego de entrada e saída não necessário para o ambiente de dados do portador do cartão.
Idem 1.2 Idem 1.2
1.2.3
Instalar firewalls de perímetro entre quaisquer redes sem fio e o ambiente de dados do portador do cartão, e configurar esses firewalls para recusar ou controlar (se esse tráfego for necessário para fins comerciais) qualquer tráfego a partir do ambiente sem fio no ambiente de dados do portador do cartão.
Idem 1.2 Idem 1.2
1.3
Proibir o acesso público direto entre a Internet e qualquer componente do sistema no ambiente de dados do portador do cartão.
Idem 1.2 Idem 1.2
1.3.1
Implementar uma DMZ para limitar o tráfego de entrada e saída somente aos protocolos que são necessários para o ambiente de dados do portador do cartão.
Idem 1.2 Idem 1.2
1.3.2 Limitar o tráfego de entrada da Internet a endereços IP na DMZ.
Idem 1.2 Idem 1.2
1.3.4 Não permitir que endereços internos sejam transmitidos via Internet na DMZ.
Idem 1.2 Idem 1.2
continua
47
continuação
1.3.5
Restringir o tráfego de saída do ambiente de dados do portador do cartão à Internet de uma forma que o tráfego de saída possa acessar somente endereços IP na DMZ.
Idem 1.2
Idem 1.2
1.36
Implementar inspeção stateful, também conhecida como filtragem de pacote dinâmico. (Ou seja, somente conexões "estabelecidas" são permitidas na rede.)
Idem 1.2 Idem 1.2
1.3.8
Implementar o mascaramento de IP para impedir que endereços internos sejam traduzidos e revelados na Internet, usando o espaço de endereço RFC 1918. Usar as tecnologias NAT (network address translation)—por exemplo, PAT (port address translation).
Idem 1.2 Idem 1.2
2.2.2
Desativar todos os serviços e protocolos desnecessários e inseguros (os serviços e protocolos que não precisam desempenhar diretamente a função especificada do dispositivo).
Nmap
Nmap permite verificar quais portas e serviços estão habilitados em um determinado sistema. Uma vez identificado os serviços e portas desnecessários para o negócio, é possível desativá-los.
3.4
Tornar o PAN ilegível em qualquer local onde ele esteja armazenado, em mídia digital portátil, mídia de back-up, em registros.
TrueCrypt TrueCrypt pode ser utilizado para cifrar o número do cartão(PAN) em qualquer dispositivo que esteja sendo armazenado.
3.5
Proteger as chaves criptográficas usadas para a criptografia dos dados do portador do cartão contra a divulgação e o uso incorreto.
StrongKey StrongKey é um sistema completo para gerenciamento de chaves criptográficas (Enterprise Key Management).
3.5.1
Restringir o acesso às chaves criptográficas ao menor número necessário de responsáveis pela proteção.
Idem 3.5 Idem 3.5
3.5.2 Armazenar chaves criptográficas de forma segura no menor número possível de locais e formatos.
Idem 3.5 Idem 3.5
3.6.1 Geração de chaves criptográficas robustas.
Idem 3.5 Idem 3.5
3.6.2 Proteger a distribuição de chaves criptográficas.
Idem 3.5 Idem 3.5
3.6.3 Proteger o armazenamento de chaves criptográficas.
Idem 3.5 Idem 3.5
3.6.4 Alterações periódicas das chaves criptográficas.
Idem 3.5 Idem 3.5
3.6.5 Inutilização ou substituição de chaves criptográficas comprometidas antigas ou suspeitas.
Idem 3.5 Idem 3.5
3.6.6 Separar o conhecimento e a determinação do controle duplo de chaves criptográficas.
Idem 3.5 Idem 3.5
3.6.7 Prevenção contra a substituição não autorizada de chaves criptográficas.
Idem 3.5 Idem 3.5
4.1
Utilizar criptografia robusta e protocolos de segurança como SSL/TLS ou IPSEC para proteger os dados confidenciais do portador do cartão durante a transmissão em redes abertas e públicas.
OpenVPN OpenSwan
Através do OpenVPN é possível implementar redes virtuais privadas com o protocolo SSL/TLS. Através do OpenSwan é possível implementar redes virtuais privadas com o protocolo IPsec.
continua
48
continuação
6.1
Certificar-se de que todos os componentes do sistema e softwares têm os patches de segurança mais recentes disponibilizados pelos fornecedores instalados.
OpenVAS Nikto
Os softwares OpenVAS e Nikto são scanners de rede que podem ser utilizados para identificar as vulnerabilidades nos sistemas que processam os dados do portador do cartão.
6.6
Para aplicativos da Web voltados ao público, abordar novas ameaças e vulnerabilidades continuamente e assegurar que esses aplicativos estejam protegidos contra ataques conhecidos.
ModSecurity DirBuster
w3af
ModSecurity é um firewall de aplicação que monitora e protege sistemas web contra ameaças de segurança. O Disbuster é uma ferramenta para bruteforce/fuzzing de diretórios. Através dele é possível encontrar arquivos que foram publicados indevidamente em um site, identificar diretórios sem autenticação, identificar interfaces de administração de banco de dados e servidores de aplicação. w3af é um framework completo para teste de aplicações web e permite não só identificar as vulnerabilidades como também explorá-las.
8.1
Atribuir a todos os usuários um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do portador do cartão.
Samba OpenLDAP OpenIAM
A implementação de um sistema de gerenciamento de identidade permite unificar os ID´s de usuários através do provisionamento de contas em repositórios de dados como o OpenLDAP ou no servidor de logon de rede como o samba.
8.2
Além de atribuir um ID exclusivo, utilize pelo menos um dos métodos a seguir para autenticar todos os usuários: * Senha ou passphrase * Autenticação com dois fatores (por exemplo, dispositivos de token, smartcard, biométrica ou chaves públicas)
Idem 8.1 Idem 8.1
8.3
Incorporar a autenticação com dois fatores para o acesso remoto à rede pelos funcionários, administradores e terceiros. Usar tecnologias como a autenticação remota e o serviço dial-in (RADIUS); sistema de controle de acesso ao controlador de acesso do terminal (TACACS) com tokens; ou VPN (baseado em SSL/TLS ou IPSEC) com certificados individuais.
OpenSSL O software OpenSSL contém scripts que permite automatizar o processo de geração de certificados digitais.
8.5.3
Definir as senhas iniciais para um valor exclusivo para cada usuário e alterar imediatamente após a primeira utilização.
Idem 8.1 Idem 8.1
8.5.4 Revogar imediatamente o acesso de quaisquer usuários desligados da empresa.
Idem 8.1 Idem 8.1
8.5.5 Remover/desativar as contas dos usuários inativos pelo menos a cada 90 dias.
Idem 8.1 Idem 8.1
8.5.6
Ativar as contas usadas pelos fornecedores somente para a manutenção remota durante o período necessário.
Idem 8.1 Idem 8.1
8.5.9 Alterar as senhas do usuário pelo menos a cada 90 dias.
Idem 8.1 Idem 8.1
8.5.10 Exigir um comprimento mínimo de senha de pelo menos sete caracteres.
Idem 8.1 Idem 8.1
continua
49
continuação
8.5.11 Usar senhas que contenham caracteres alfanuméricos.
Idem 8.1 Idem 8.1
8.5.12
Não permitir que ninguém utilize uma nova senha que seja a mesma de uma das quatro últimas senhas que tenha sido usada.
Idem 8.1 Idem 8.1
8.5.13 Limitar tentativas de acesso repetidas e bloquear o ID do usuário após seis tentativas, no máximo.
Idem 8.1 Idem 8.1
8.5.14 Definir a duração do bloqueio para um mínimo de 30 minutos ou até o administrador ativar o ID do usuário.
Idem 8.1 Idem 8.1
8.5.15 Se uma sessão estiver ociosa por mais de 15 minutos, exigir que o usuário redigite a senha para reativar o terminal.
Idem 8.1
Idem 8.1
10.4 Sincronizar todos os relógios e horários do sistema crítico.
NTPD
NTPD é um software que fornece serviço de sincronização de horário.
10.5 Proteger as trilhas de auditoria para que não possam ser alteradas.
OSSEC Osiris
OSSEC é um HIDS (Host-based Intrusion Detection System) que realiza análise de logs e verificação de integridade de arquivos. Osiris é um software para monitorar a integridade do filesystem, logs, módulos do kernel e lista de usuários.
10.5.3
Fazer imediatamente o back-up dos arquivos de trilha de auditoria em um servidor de registros centralizado ou mídias que sejam difíceis de alterar.
Syslog-ng OSSEC
Syslog-ng é um software que permite criar um servidor centralizado de logs. OSSEC é um HIDS (Host-based Intrusion Detection System) que realiza análise de logs e verificação de integridade de arquivos.
10.5.4 Documentar registros quanto às tecnologias externas em um servidor de registros na LAN interna.
Idem 10.5.3 Idem 10.5.3
10.5.5
Usar softwares de monitoramento da integridade dos arquivos ou de detecção de alterações nos registros para assegurar que os dados de registro existentes não possam ser alterados sem gerar alertas.
Idem 10.5 Idem 10.5
10.7
Manter um histórico da trilha de auditoria por pelo menos um ano, com um mínimo de três meses imediatamente disponível para análise (por exemplo, online, arquivado ou recuperável a partir do back-up).
Idem 10.5.3 Idem 10.5.3
11.1
Testar a presença de pontos de acesso sem fio usando um analisador sem fio pelo menos trimestralmente ou implementando um IDS/IPS sem fio para identificar todos os dispositivos sem fio que estão sendo usados.
Kismet Kismet é um analisador que permite detectar redes sem fio não autorizadas.
11.2
Procurar por vulnerabilidade nas redes internas e externas pelo menos trimestralmente e após qualquer mudança significativa na rede (como instalações de novos componentes do sistema, mudanças na topologia da rede, modificações das normas do firewall, upgrades de produtos).
Idem 6.1 Idem 6.1
continua
50
continuação
11.3
Realizar testes de penetração externos e internos pelo menos uma vez por ano e após qualquer upgrade ou modificação significativa na infra-estrutura ou nos aplicativos (como um upgrade no sistema operacional, uma sub-rede adicionada ao ambiente ou um servidor da web adicionado ao ambiente).
Metasploit Com o metasploit é possível realizar testes de penetração na rede, procurando por vulnerabilidades na rede e sistemas.
11.3.1 Testes de penetração na camada da rede.
Idem 11.3 Idem 11.3
11.3.2 Testes de penetração na camada dos aplicativos
Idem 11.3 w3af
Idem 11.3 w3af é um framework completo para teste de aplicações web e permite não só identificar as vulnerabilidades como também explorá-las.
11.4
Usar sistemas de detecção de invasão e/ou sistemas de prevenção contra invasão para monitorar todo o tráfego no ambiente de dados do portador do cartão e alertar as equipes sobre comprometimentos suspeitos. Manter todos os mecanismos de detecção e prevenção contra invasões atualizados.
Snort Prelude
Snort é um IDS/IPS (Network Intrusion Detection and Prevention System) e pode ser utilizado para monitorar o ambiente dos dados do portador do cartão. Prelude é um IDS (Intrusion Detection System) e pode ser utilizado para monitorar o ambiente dos dados do portador do cartão.
11.5
Implementar softwares de monitoramento da integridade dos arquivos para alertar as equipes quanto à modificação não autorizada de arquivos críticos do sistema, arquivos de configuração ou arquivos de conteúdo; e configurar o software para realizar comparações de arquivos críticos pelo menos semanalmente.
Idem 10.5 Idem 10.5
Quadro 9 - Ferramentas para atender os requisitos técnicos do PCI DSS Fonte: Elaborado pelo autor
O quadro 9 detalha as ferramentas selecionadas e incluídas no toolkit, que poderão ser
utilizadas para auxiliar durante o atendimento dos requisitos técnicos do PCI DSS. Através
desta tabela é possível verificar que apenas uma ferramenta pode atender diversos requisitos
do PCI DSS, uma vez que tal ferramenta atende a intenção dos mesmos.
Através de análise da documentação oficial do PCI Council, verifica-se que o
OpenPCI Toolkit atende cinqüenta e três requisitos técnicos do PCI DSS através de vinte e
sete ferramentas selecionadas. Os demais requisitos técnicos estão relacionados a atividades
como instalação de antivírus, controle de acesso físico e desenvolvimento seguro, por
exemplo, aos quais o OpenPCI Toolkit não possui ferramentas.
51
4.3 Projetos Relacionados
Com a criação do PCI DSS e a necessidade de adequação das empresas em relação aos
requisitos exigidos, algumas soluções foram criadas com o intuito de auxiliar no processo de
conformidade.
Entre as soluções pesquisadas durante a elaboração deste trabalho, verificou-se que
nenhuma delas inclui ferramentas sem custo de aquisição e que possam ser utilizadas para
atender os requisitos técnicos do PCI DSS.
O quadro 10 irá apresentar as soluções pesquisadas e como elas pretendem auxiliar no
processo de conformidade com o PCI DSS:
Projeto Descrição Fornecedor Licença
PCI Toolkit Interface web para gerenciar o SAQ,
programas de treinamento em segurança
da informação, exemplos de políticas.
CSRSI Comercial
PCI DSS V1.2
Documentation
Compliance Toolkit
Documentações, livros e mapeamento
com a ISO 27001.
IT Governance
UK
Comercial
PCI Toolkit Interface web para gerenciar o SAQ e
documentações complementares sobre o
PCI DSS.
GoToBilling Comercial
realPCI Sistema de gestão para gerenciar o
atendimento dos controles aplicados,
relatórios e gerenciamento de risco.
Realiso Corp Comercial
Quadro 10 - Projetos que visam auxiliar no processo de conformidade com o PCI DSS Fonte: Elaborado pelo Autor.
De acordo com o quadro 10, é possível verificar que todas as soluções estão focadas
na disponibilização de documentações ou na apresentação do SAQ através de uma interface
web, embora nenhuma delas tenha como propósito disponibilizar ferramentas para atender
especificamente os requisitos técnicos, como segmentação da rede, análise de
vulnerabilidades, gerenciamento de logs, entre outros.
52
Avaliando tais soluções, verifica-se que o OpenPCI Toolkit preenche uma lacuna
existente entre as soluções atuais, que é o atendimento dos requisitos técnicos, assim
fornecendo uma alternativa importante para estabelecimentos comerciais e prestadores de
serviço que necessitam estar aderentes ao PCI DSS e reduzir o custo com a implementação
dos controles.
53
5 CONSIDERAÇÕES FINAIS
A realização de fraudes envolvendo cartões de crédito e débito é uma das
conseqüências negativas da popularização deste meio de pagamento eletrônico que é
amplamente utilizado no mundo todo.
Tais fraudes são direcionadas tanto para o portador do cartão, como para as empresas
que manipulam um grande volume de dados de cartões. Nos últimos anos, houve registros de
casos nos EUA onde o número de cartões comprometidos chegou a mais de 200 milhões.
Esta monografia apresenta um toolkit, cujo objetivo é disponibilizar ferramentas
isentas de custo de aquisição para auxiliar as empresas que processam, transmitem ou
armazenam os dados de cartões de crédito e débito a atender os requisitos técnicos do PCI
DSS (Padrão de Segurança da Indústria de Cartões de Pagamento), que foi criado para reduzir
a possibilidade de fraudes envolvendo tais dados.
O toolkit, nomeado como OpenPCI, organiza as ferramentas de acordo com cada
requisito do PCI DSS e através de um instrumento para análise de aderência (SAQ), é
possível verificar como tal ferramenta poderá auxiliar no atendimento do requisito não-
conforme. Durante o desenvolvimento deste trabalho, não foi identificado soluções com o
mesmo propósito do OpenPCI Toolkit, sendo que as outras soluções existentes são comerciais
e possuem um custo elevado para aquisição e manutenção de licenças de uso.
Devido a isto, considera-se que o OpenPCI seja uma alternativa que possibilite as
empresas reduzir o custo do processo de conformidade, no que diz respeito à aquisição de
ferramentas e manutenção de licenças. Neste sentido, entende-se que o OpenPCI Toolkit
poderá ser utilizado tanto por grandes empresas como por pequenos estabelecimentos
comerciais.
54
5.1 Contribuições
Apesar de ser um projeto recente, o OpenPCI Toolkit foi amplamente divulgado e já é
de conhecimento de diversos profissionais e empresas do mercado de cartões de crédito. Entre
as diversas atividades executadas para divulgar este projeto é possível citar algumas que são
de extrema importância para o seu crescimento e popularização.
• Publicação do artigo Conformidade: Por onde Começar?, na revista eletrônica
da ISSA Brasil (Information Systems Security Association).
• Publicação e apresentação do artigo OpenPCI: Um toolkit para atender os
requisitos técnicos do PCI DSS, no SBSEG 2009 realizado no centro de
convenções da Unicamp - Campinas.
• Criação de um blog para divulgar o projeto e fornecer informações sobre o PCI
DSS e fraudes.
• Mais de 140 downloads em menos de um mês após o lançamento da primeira
versão do toolkit (Fonte: Site do CódigoLivre e SourceForge).
Após a criação do projeto, alguns sites e profissionais do mercado de cartões também
começaram a divulgar o projeto, o que demonstra o grande interesse pelo assunto. Tais
divulgações estão listadas a seguir:
• OpenPCI Toolkit disponível para download (NEVES, 2009).
• OpenPCI Toolkit – Tecnologia para cartões de pagamento (BR-LINUX,
2009).
• Citação no portal internacional IT Security (DUBIN, 2009).
5.2 Trabalhos Futuros
Para a continuidade deste projeto, sugere-se algumas atividades para trabalhos futuros,
como a inclusão de novas ferramentas, manter o toolkit com as últimas atualizações da
distribuição Ubuntu, criar novos módulos para o SAQ, como por exemplo, gráficos para o
55
acompanhamento dos índices de conformidade, uma interface web e documentações mais
completas sobre os requisitos do PCI DSS e as ferramentas incluídas.
Cabe salientar que se tentou realizar uma avaliação experimental do toolkit, mas não
foi possível devido ao baixo número de respostas ao questionário de avaliação criado para
este propósito. Sendo assim, este toolkit ainda carece de uma avaliação mais completa por
parte dos usuários e interessados pelo projeto.
56
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DAS EMPRESAS DE CARTÃO DE CRÉDITO E SERVIÇOS - ABECS. Indicadores mensais. Disponível em: <http://www.abecs.org.br/>. Acesso em: 4 abr. 2009.
BEZERRA, Carlos. Projeto de Lei n. 1547, de 2007. Disponível em: <http://www.camara. gov.br/sileg/integras/481739.pdf>. Acesso em: 2 maio 2009.
BR-LINUX. OpenPCI toolkit: tecnologia para cartões de pagamento. Disponível em: <http://br-linux.org/2009/openpci-toolkit-tecnologia-para-cartoes-de-pagamento/>. Acesso em: 23 out. 2009.
CENTRO DE ATENDIMENTO A INCIDENTES DE SEGURANÇA - CAIS. Fraudes identificadas e divulgadas pelo CAIS. Disponível em: <http://www.rnp.br/cais/fraudes.php> Acesso em: 31 out. 2009.
CENTRO DE ESTUDOS SOBRE AS TECNOLOGIAS DA INFORMAÇÃO E DA COMUNICAÇÃO - CETIC. Pesquisa sobre o uso das tecnologias da informação e da comunicação no Brasil. Disponível em: <http://www.cetic.br/usuarios/ tic/2008/analise-tic-domicilios-parte2-2008.pdf>. Acesso em: 3 maio 2009.
COMMONWEALTH BANK. ATM card skimming & PIN capturing customer awareness guide. Disponível em: < http://www.commbank.com.au/personal/apply-online/download-printed-forms/ATM_awareness_guide.pdf>. Acesso em: 6 maio 2009.
DUBIN, Joel. Dubin's IT security portal. Disponível em: <http://joeldubin.com/>. Acesso em: 23 out. 2009.
GOOGLE CODE. Disponível em: <http://code.google.com/intl/pt-BR/>. Acesso em: 19 out. 2009.
GOOGLE WEB TOOLKIT. Disponível em: <http://code.google.com/intl/pt-BR/webtoolkit/>. Acesso em: 19 out. 2009.
IBM MIGRATION TOOLKIT. Disponível em: <http://www-01.ibm.com/software/data/db2/ migration/mtk/>. Acesso em: 19 out. 2009.
JOHNSON, Bryan. What does it cost to become PCI compliant? Disponível em: <http:// www.braintreepaymentsolutions.com/blog/what-does-it-cost-to-become-pci-compliant/>. Acesso em: 9 maio 2009.
57
NAKAYA, Paulo. Pesquisas e novos produtos no campo da identificação civil. Disponível em: <http://enterprise.tse.gov.br/eje/arquivos/publicacoes/seminario/html/seminario_justica _eleitoral.pdf >. Acesso em: 16 maio 2009.
NETWORK SECURITY TOOLKIT - NST. Disponível em: <http://www.networksecurity toolkit. org/nst/index.html>. Acesso em: 19 out. 2009.
NEUKAMP, Paulo. FDTK-UbuntuBR. Disponível em: <http://www.fdtk.com.br/ wordpress/>. Acesso em: 19 out. 2009.
NEVES, Eduardo Vianna de Camargo. Open PCI toolkit. Disponível em: <http:// camargoneves.com/2009/10/open-pci-toolkit-disponivel-para-download/>. Acesso em: 23 out. 2009.
NOVAK, Christopher. Data breach investigations report, 2009. Disponível em: <http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf>. Acesso em: 11 abr. 2009.
ORACLE. Technology Global Price List. Disponível em: <http://www.oracle.com/ corporate/pricing/technology-price-list.pdf>. Acesso em: 14 maio 2009.
PARODI, Lorenzo. Manual das fraudes. 2. ed. Rio de Janeiro: Brasport, 2008
PCI SECURITY STANDARDS COUNCIL. Disponível em: < https://www.pcisecurity standards.org/>. Acesso em: 10 abr. 2009.
PCI SECURITY STANDARDS COUNCIL. Navigating PCI DSS. Understanding the intent of the requirements. 2008. Disponível em: <https://www.pcisecuritystandards .org/pdfs/ pci_dss_saq_navigating_dss.pdf>. Acesso em: 20 maio 2009.
PERETTI, Kimberly Kiefer. Data breaches: what the underground world of “carding” reveals. Disponível em: <http://www.usdoj.gov/criminal/cybercrime/DataBreaches Article.pdf>. Acesso em: 22 maio 2009.
REDECARD. Disponível em: <https://services.redecard.com.br/novoportal/site/ 3552/P%C3%A1gina_Inicial_de_Biblioteca.aspx>. Acesso em: 25 maio 2009.
SOLARIS SECURITY TOOLKIT. Disponível em: <http://www.sun.com/software/ security/jass/>. Acesso em: 19 out. 2009.
58
THAKAR, Sumedh; RAMOS, Terry. PCI compliance for Dummies. Disponível em: <http://www.qualys.com/forms/ebook/pcifordummies/>. Acesso em: 26 maio 2009.
VIRTUE, Timothy M. Payment card industry data security standard handbook. USA: Wiley, 2009
VISA. Disponível em: <http://visa.com/cisp>. Acesso em: 5 jun. 2009.
WIENER. Senate Bill no. 227. Disponível em: <https://www.leg.state.nv.us/75th2009 /Bills/SB/SB227_EN.pdf>. Acesso em: 7 jun. 2009.
ZENITY. Disponível em: <http://live.gnome.org/Zenity>. Acesso em: 19 out. 2009.