• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Um Toolkit para atender os requisitos técnicos do PCI DSS

  • 2,894 views
Uploaded on

Trabalho de conclusão do curso superior em Segurança da Informação - Unisinos.

Trabalho de conclusão do curso superior em Segurança da Informação - Unisinos.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
2,894
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
51
Comments
1
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. Para minha amada esposa Cristina, que me ensinou o verdadeiro sentido da palavra dedicação.
  • 4. 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.
  • 5. 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.
  • 6. 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.
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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.
  • 14. 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).
  • 15. 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).
  • 16. 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 é
  • 17. 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.
  • 18. 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.
  • 19. 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.
  • 20. 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.
  • 21. 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:
  • 22. 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.
  • 23. 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
  • 24. 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.
  • 25. 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
  • 26. 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 239 mil cartões de crédito e débito 2005 eletrônicas 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 Processadora de transações 1.5 milhões de cartões de crédito 2008 WordPay eletrônicas Heartland Processadora de transações 130 milhões de cartões de crédito e débito 2009 eletrônicas Network Processadora de transações 573.928 mil cartões de crédito 2009 Solutions eletrônicas 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
  • 27. 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.
  • 28. 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 Information Security & Compliance Discover (DISC) JCB Data Security Program (DSP) Quadro 2 - Programas de segurança das bandeiras de cartão Fonte: Elaborado pelo autor.
  • 29. 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 Número do cartão Sim Dados do portador do Nome do portador do cartão Sim cartão Código de serviço Sim Data de vencimento Sim Dados completos da tarja magnética Não Dados de autenticação CAV2/CVC2/CVV2/CID Não confidenciais 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
  • 30. 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 PA-DSS (Payment Application PCI DSS (Data Security PCI PED (PIN Entry Devices) Data Security Standard) 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.
  • 31. 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:
  • 32. 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.
  • 33. 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.
  • 34. 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.
  • 35. 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
  • 36. 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 Modelo de Validação Descrição SAQ do SAQ 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 1 A do cartão são terceirizadas. Esta categoria nunca se aplica a estabelecimentos com vendas presenciais. Estabelecimentos com máquina de carbono, sem retenção eletrônica dos 2 B dados do portador do cartão. Estabelecimentos de terminal de discagem independente, sem retenção 3 B eletrônica dos dados do portador do cartão. Estabelecimentos com sistemas de PDV conectados à Internet, sem 4 C retenção eletrônica dos dados do portador do cartão. Todos os outros estabelecimentos (não incluídos nas descrições dos 5 SAQ A-C acima) e todos os prestadores de serviço definidos por uma D bandeira como qualificados para preencherem um SAQ. 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.
  • 37. 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 Relatório de conformidade anual emitido por um QSA. Análise trimestral da rede, executado por um ASV. 1 Mais de 6 milhões de transações. Formulário de atestado de conformidade emitido pelo adquirente. Emissão de um Self-Assessment Questionnaire (SAQ) anualmente. 2 Entre 1 e 6 milhões de transações. Análise trimestral da rede, executado por um ASV. Formulário de atestado de conformidade emitido pelo adquirente. Emissão de um Self-Assessment Questionnaire (SAQ) anualmente. 3 Entre 20 mil e 1 milhão de Análise trimestral da rede, executado por um ASV. transações (e-commerce). Formulário de atestado de conformidade emitido pelo adquirente. Recomendado a emissão de um Self-Assessment Questionnaire (SAQ). 4 Menos de 20 mil transações (e- Análise trimestral da rede, executado por um ASV (se commerce). 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 Análise de segurança On-Site por um QSA. 1 Mais de 300 mil transações. Análise trimestral da rede, executado por um ASV. Menos de 300 mil transações Emissão de um SAQ anualmente. 2 por ano. 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
  • 38. 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.
  • 39. 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 Custo aproximado em Requisito do Ferramenta Fabricante dólar PCI DSS Power-1 Security Appliances Checkpoint $36.500 1, 4 5070 Barracuda Web Application Barracuda Networks $17.000 6 Firewall 660 Oracle Identity Management Oracle $270.000 8 RSA EnVision RSA $160.000 10 Retina Network Security eEye Digital $1.650 11 Scanner Security 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.
  • 40. 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.
  • 41. 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.
  • 42. 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.
  • 43. 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
  • 44. 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.
  • 45. 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.
  • 46. 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.
  • 47. 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 Diagrama da rede atual com todas as Dia O software Dia permite criar diagramas da conexões com relação aos dados do 1.1.2 rede, identificando todas as conexões com o portador do cartão, incluindo quaisquer ambiente dos dados do portador do cartão. redes sem fio. O iptables é a ferramenta que permite criar e Elaborar uma configuração do firewall administrar as regras de firewall e NAT na que restrinja as conexões entre redes Iptables versão 2.6 do kernel Linux. Através dele, é 1.2 não confiáveis e quaisquer componentes Firewall Builder possível isolar a rede que processa os dados do do sistema no ambiente de dados do portador do cartão das demais redes. O portador do cartão. Firewall Builder permite administrar estas regras através de uma interface gráfica. Restringir o tráfego de entrada e saída 1.2.1 não necessário para o ambiente de Idem 1.2 Idem 1.2 dados do portador do cartão. 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 1.2.3 ou controlar (se esse tráfego for Idem 1.2 Idem 1.2 necessário para fins comerciais) qualquer tráfego a partir do ambiente sem fio no ambiente de dados do portador do cartão. Proibir o acesso público direto entre a Internet e qualquer componente do 1.3 Idem 1.2 Idem 1.2 sistema no ambiente de dados do portador do cartão. Implementar uma DMZ para limitar o tráfego de entrada e saída somente aos 1.3.1 protocolos que são necessários para o Idem 1.2 Idem 1.2 ambiente de dados do portador do cartão. Limitar o tráfego de entrada da Internet 1.3.2 Idem 1.2 Idem 1.2 a endereços IP na DMZ. Não permitir que endereços internos 1.3.4 sejam transmitidos via Internet na Idem 1.2 Idem 1.2 DMZ. continua
  • 48. 47 continuação Idem 1.2 Restringir o tráfego de saída do ambiente de dados do portador do 1.3.5 cartão à Internet de uma forma que o Idem 1.2 tráfego de saída possa acessar somente endereços IP na DMZ. Implementar inspeção stateful, também conhecida como filtragem de pacote 1.36 Idem 1.2 Idem 1.2 dinâmico. (Ou seja, somente conexões "estabelecidas" são permitidas na rede.) 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 1.3.8 Idem 1.2 Idem 1.2 1918. Usar as tecnologias NAT (network address translation)—por exemplo, PAT (port address translation). Desativar todos os serviços e protocolos Nmap permite verificar quais portas e serviços desnecessários e inseguros (os serviços estão habilitados em um determinado sistema. 2.2.2 e protocolos que não precisam Nmap Uma vez identificado os serviços e portas desempenhar diretamente a função desnecessários para o negócio, é possível especificada do dispositivo). desativá-los. Tornar o PAN ilegível em qualquer local onde ele esteja armazenado, em TrueCrypt pode ser utilizado para cifrar o 3.4 mídia digital portátil, mídia de back-up, TrueCrypt número do cartão(PAN) em qualquer em registros. dispositivo que esteja sendo armazenado. Proteger as chaves criptográficas usadas StrongKey é um sistema completo para para a criptografia dos dados do 3.5 StrongKey gerenciamento de chaves criptográficas portador do cartão contra a divulgação e (Enterprise Key Management). o uso incorreto. Restringir o acesso às chaves criptográficas ao menor número 3.5.1 Idem 3.5 Idem 3.5 necessário de responsáveis pela proteção. Armazenar chaves criptográficas de 3.5.2 forma segura no menor número possível Idem 3.5 Idem 3.5 de locais e formatos. Geração de chaves criptográficas 3.6.1 Idem 3.5 Idem 3.5 robustas. Proteger a distribuição de chaves 3.6.2 Idem 3.5 Idem 3.5 criptográficas. Proteger o armazenamento de chaves 3.6.3 Idem 3.5 Idem 3.5 criptográficas. Alterações periódicas das chaves 3.6.4 Idem 3.5 Idem 3.5 criptográficas. Inutilização ou substituição de chaves 3.6.5 criptográficas comprometidas antigas Idem 3.5 Idem 3.5 ou suspeitas. Separar o conhecimento e a 3.6.6 determinação do controle duplo de Idem 3.5 Idem 3.5 chaves criptográficas. Prevenção contra a substituição não 3.6.7 Idem 3.5 Idem 3.5 autorizada de chaves criptográficas. Utilizar criptografia robusta e Através do OpenVPN é possível implementar protocolos de segurança como SSL/TLS redes virtuais privadas com o protocolo ou IPSEC para proteger os dados OpenVPN SSL/TLS. 4.1 Através do OpenSwan é possível implementar confidenciais do portador do cartão OpenSwan durante a transmissão em redes abertas redes virtuais privadas com o protocolo IPsec. e públicas. continua
  • 49. 48 continuação Certificar-se de que todos os Os softwares OpenVAS e Nikto são scanners componentes do sistema e softwares OpenVAS de rede que podem ser utilizados para 6.1 têm os patches de segurança mais Nikto identificar as vulnerabilidades nos sistemas que recentes disponibilizados pelos processam os dados do portador do cartão. fornecedores instalados. ModSecurity é um firewall de aplicação que monitora e protege sistemas web contra ameaças de segurança. O Disbuster é uma ferramenta para Para aplicativos da Web voltados ao bruteforce/fuzzing de diretórios. Através dele é público, abordar novas ameaças e ModSecurity possível encontrar arquivos que foram 6.6 vulnerabilidades continuamente e DirBuster publicados indevidamente em um site, assegurar que esses aplicativos estejam w3af identificar diretórios sem autenticação, protegidos contra ataques conhecidos. 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. A implementação de um sistema de gerenciamento de identidade permite unificar Atribuir a todos os usuários um ID os ID´s de usuários através do Samba exclusivo antes de permitir que eles provisionamento de contas em repositórios de 8.1 OpenLDAP acessem os componentes do sistema ou dados como o OpenLDAP ou no servidor de OpenIAM os dados do portador do cartão. logon de rede como o samba. 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 8.2 Idem 8.1 Idem 8.1 * Autenticação com dois fatores (por exemplo, dispositivos de token, smartcard, biométrica ou chaves públicas) Incorporar a autenticação com dois fatores para o acesso remoto à rede pelos funcionários, administradores e terceiros. Usar tecnologias como a O software OpenSSL contém scripts que autenticação remota e o serviço dial-in 8.3 OpenSSL permite automatizar o processo de geração de (RADIUS); sistema de controle de certificados digitais. acesso ao controlador de acesso do terminal (TACACS) com tokens; ou VPN (baseado em SSL/TLS ou IPSEC) com certificados individuais. Definir as senhas iniciais para um valor exclusivo para cada usuário e alterar 8.5.3 Idem 8.1 Idem 8.1 imediatamente após a primeira utilização. Revogar imediatamente o acesso de 8.5.4 quaisquer usuários desligados da Idem 8.1 Idem 8.1 empresa. Remover/desativar as contas dos 8.5.5 usuários inativos pelo menos a cada 90 Idem 8.1 Idem 8.1 dias. Ativar as contas usadas pelos fornecedores somente para a 8.5.6 Idem 8.1 Idem 8.1 manutenção remota durante o período necessário. Alterar as senhas do usuário pelo menos 8.5.9 Idem 8.1 Idem 8.1 a cada 90 dias. Exigir um comprimento mínimo de 8.5.10 Idem 8.1 Idem 8.1 senha de pelo menos sete caracteres. continua
  • 50. 49 continuação Usar senhas que contenham caracteres 8.5.11 Idem 8.1 Idem 8.1 alfanuméricos. Não permitir que ninguém utilize uma nova senha que seja a mesma de uma 8.5.12 Idem 8.1 Idem 8.1 das quatro últimas senhas que tenha sido usada. Limitar tentativas de acesso repetidas e 8.5.13 bloquear o ID do usuário após seis Idem 8.1 Idem 8.1 tentativas, no máximo. Definir a duração do bloqueio para um 8.5.14 mínimo de 30 minutos ou até o Idem 8.1 Idem 8.1 administrador ativar o ID do usuário. Idem 8.1 Se uma sessão estiver ociosa por mais 8.5.15 de 15 minutos, exigir que o usuário Idem 8.1 redigite a senha para reativar o terminal. Sincronizar todos os relógios e horários NTPD NTPD é um software que fornece serviço de 10.4 do sistema crítico. sincronização de horário. OSSEC é um HIDS (Host-based Intrusion Detection System) que realiza análise de logs OSSEC e verificação de integridade de arquivos. Proteger as trilhas de auditoria para que 10.5 Osiris Osiris é um software para monitorar a não possam ser alteradas. integridade do filesystem, logs, módulos do kernel e lista de usuários. Syslog-ng é um software que permite criar um Fazer imediatamente o back-up dos servidor centralizado de logs. Syslog-ng arquivos de trilha de auditoria em um OSSEC é um HIDS (Host-based Intrusion 10.5.3 OSSEC servidor de registros centralizado ou Detection System) que realiza análise de logs mídias que sejam difíceis de alterar. e verificação de integridade de arquivos. Documentar registros quanto às 10.5.4 tecnologias externas em um servidor de Idem 10.5.3 Idem 10.5.3 registros na LAN interna. Usar softwares de monitoramento da integridade dos arquivos ou de detecção de alterações nos registros para 10.5.5 Idem 10.5 Idem 10.5 assegurar que os dados de registro existentes não possam ser alterados sem gerar alertas. Manter um histórico da trilha de auditoria por pelo menos um ano, com um mínimo de três meses imediatamente disponível 10.7 Idem 10.5.3 Idem 10.5.3 para análise (por exemplo, online, arquivado ou recuperável a partir do back- up). Testar a presença de pontos de acesso sem fio usando um analisador sem fio pelo menos trimestralmente ou Kismet é um analisador que permite detectar 11.1 Kismet implementando um IDS/IPS sem fio redes sem fio não autorizadas. para identificar todos os dispositivos sem fio que estão sendo usados. Procurar por vulnerabilidade nas redes internas e externas pelo menos trimestralmente e após qualquer mudança significativa na rede (como 11.2 Idem 6.1 Idem 6.1 instalações de novos componentes do sistema, mudanças na topologia da rede, modificações das normas do firewall, upgrades de produtos). continua
  • 51. 50 continuação Realizar testes de penetração externos e internos pelo menos uma vez por ano e após qualquer upgrade ou modificação Com o metasploit é possível realizar testes de significativa na infra-estrutura ou nos 11.3 Metasploit penetração na rede, procurando por aplicativos (como um upgrade no vulnerabilidades na rede e sistemas. sistema operacional, uma sub-rede adicionada ao ambiente ou um servidor da web adicionado ao ambiente). Testes de penetração na camada da 11.3.1 Idem 11.3 Idem 11.3 rede. Idem 11.3 Testes de penetração na camada dos Idem 11.3 w3af é um framework completo para teste de 11.3.2 aplicativos w3af aplicações web e permite não só identificar as vulnerabilidades como também explorá-las. Snort é um IDS/IPS (Network Intrusion Usar sistemas de detecção de invasão Detection and Prevention System) e pode ser e/ou sistemas de prevenção contra utilizado para monitorar o ambiente dos dados invasão para monitorar todo o tráfego Snort do portador do cartão. no ambiente de dados do portador do 11.4 Prelude Prelude é um IDS (Intrusion Detection cartão e alertar as equipes sobre System) e pode ser utilizado para monitorar o comprometimentos suspeitos. Manter ambiente dos dados do portador do cartão. todos os mecanismos de detecção e prevenção contra invasões atualizados. Implementar softwares de monitoramento da integridade dos arquivos para alertar as equipes quanto à modificação não autorizada de 11.5 arquivos críticos do sistema, arquivos Idem 10.5 Idem 10.5 de configuração ou arquivos de conteúdo; e configurar o software para realizar comparações de arquivos críticos pelo menos semanalmente. 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.
  • 52. 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, CSRSI Comercial programas de treinamento em segurança da informação, exemplos de políticas. PCI DSS V1.2 Documentações, livros e mapeamento IT Governance Comercial Documentation com a ISO 27001. UK Compliance Toolkit PCI Toolkit Interface web para gerenciar o SAQ e GoToBilling Comercial documentações complementares sobre o PCI DSS. realPCI Sistema de gestão para gerenciar o Realiso Corp Comercial atendimento dos controles aplicados, relatórios e gerenciamento de risco. 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.
  • 53. 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.
  • 54. 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.
  • 55. 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
  • 56. 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.
  • 57. 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.
  • 58. 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.
  • 59. 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.