Segurança da Informação blog - PCI

OS 12 requerimentos do PCI DSS 1.2

Claudio Oliveira — Thu, 23 Jul 2009 18:40:01 GMT

O Payment Card Industry - Security Standards Council (PCI SSC) apresentou em 01 de Outubro de 2008, a nova versão dos padrões de segurança para a segurança para transações com cartões de crédito.

Esta nova versão é o resultado de dois anos de desenvolvimento e contribuições de diversas empresas do mercado financeiro mundial. Está incluso nesta nova versão, o detalhamento sobre os doze requisitos de segurança para a proteção e segurança das informações do portados do cartão.

Com o grande crescimento das transações de dinheiro de plástico no mundo e no Brasil (entre 2003 a 2008 foi 129% de crescimento de acordo com o BC somente para transações de cartão de crédito), a preocupação em salvaguardar as informações confidenciais dos clientes, bem como, as transações correntes, é cada vez maior, dessa forma a devida adoção desses padrões alem de auxiliar em elevar os níveis de seguranças dessas transações ajuda a garantir a confidencialidade e integridade das informações dos clientes.

Da mesma forma as fraudes quase nunca divulgadas pelas empresas financeiras devem estar crescendo em proporções parecidas. A falta de divulgação pelas empresas financeiras só reforça que a devida adoção dos requerimentos do PCI DSS protege esses ativos.

Para facilitar o entendimento sobre esses requerimentos estarei apresentado cada um deles com explicações básicas:

Construir e manter uma rede segura

Acreditem por tão simples e obvio que essa recomendação pareça mais de 99% dos crimes cibernéticos, ocorrem usando redes desprotegidas, mal configuradas e sem controle sobre as alterações e mudanças (gestão de mudanças).

Requisito 1 - “Instalar e manter uma configuração de firewalls para proteger os dados do portador do cartão”.

Neste requisito deve ser implementado um firewall com configurações de segurança que protejam as redes, implementar DMZ (Zonas Desmilitarizadas), não permitir comunicação entre as redes de Internet e redes protegidas (redes onde contém informações sobre os cartões), implementar NAT para prover acesso aos serviços da rede interna e DMZ e por ultimo manter um firewall pessoal instalado e configurado estações de trabalho que acessam os ambientes de Internet e redes protegidas.

Requisito 2 - “Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança”.

Para este requisito a maior recomendação é alterar as configurações e senhas padrões em softwares e hardwares fornecidos para atender o ambiente tecnológico compreendido. Desabilitar serviços e protocolos desnecessários para o ambiente, bem como, remover e desabilitar usuários padrões e desnecessários.

Proteger os dados do portador do cartão

Proteger as informações é o maior foco de todas as demandas do PCI DSS, desta forma todos os mecanismos estão voltados para garantir a confidencialidade e integridade dessas informações.

Requisito 3 - “Proteger os dados armazenados do portador do cartão”.

Algumas atividades devem ser feitas neste controle, entre elas definir políticas de retenção das informações dos cartões, não armazenar os dados do portador do cartão de forma indiscriminada e desnecessária, para o devido armazenamento utilizar criptografia adequada para o Banco de Dados, não compartilhar as informações do portador do cartão em mídias magnéticas ou de forma indiscriminada, nunca armazene o número do cartão juntamente com o código de segurança, é necessário mascarar os dados do portador do cartão armazenados, entre outros.

Requisito 4 - “Criptografar as transmissões dos dados do portador do cartão em redes abertas e públicas.”

Para as transmissões das informações devem utilizar criptografia forte, para transmissões em redes sem fio (Wireless) deve utilizar as melhores práticas de mercado ex: usar IEEE 802.11i, proibido o uso de chaves Wep, utilizar criptografia forte, etc. Por ultimo nunca envie informações por e-mail, instant messaging, chat sem a devido criptografia e proteção.

Manter um programa de gerenciamento de vulnerabilidades

O famoso Change Management é altamente aplicável, pois o controle dos patch’s de seguranças para os ambientes serão imprescindíveis neste momento.

Requisito 5 - “Utilizar e atualizar regularmente softwares antivírus”.

Este requisito é muito simples, é obrigatório o uso de mecanismo de antivírus ativo e capaz de gerar log’s para os eventos e futuras analises e com engine e assinatura mais recente.

Requisito 6 - “Desenvolver e manter sistemas e aplicativos seguros”.

Para todos os sistemas e aplicativos que foram utilizados diretamente para suportar e auxiliar no funcionamento das transações de cartão de créditos, os mesmos devem ter controle de versão, gestão de atualização (Patch’s de Segurança), prazo máximo de 30 dias para a ultima atualização de segurança implementada, ter um processo de descoberta de vulnerabilidade, desenvolver os sistemas e aplicativos de acordo com as melhores práticas de mercado ao que tange segurança, validação de entradas e mascaras de dados, utilizar criptografia se necessário, guardar em local protegido e seguro o código fonte das aplicações e sistemas, entre outras implementações.

Implementar medidas de controle de acesso rigorosas

É necessário ter uma política de controle de acesso, para garantir que todos os requisitos de segurança relacionados aos acessos dos usuários nos sistemas sejam aplicados, bem como a manutenção desse acesso se faz necessário.

Requisito 7 – “Restringir o acesso aos dados do portador do cartão de acordo com a necessidade de divulgação dos negócios”.

Os acessos aos dados do cartão, deve ser segmentado com perfis de acesso de acordo com a necessidade dos negócios, os acessos devem ser individualizados não permitindo usuários genéricos ou anônimos, políticas de senhas deve ser implementada e mecanismos de segurança para gestão dos acessos devem ser aplicados.

Requisito 8 – “Atribuir um ID exclusivo para cada pessoa que tenha acesso a um computador”.

Cada usuário deve ter seu user-ID exclusivo, com no mínimo dois fator de autenticação (ex: Token, smartcard, biometria ou certificado digital).

Requisito 9 – “Restringir o acesso físico aos dados do portador do cartão”.

Utilize mecanismos de segurança (fechaduras eletrônicas abertas por biometria, smartcard, etc.) para restringir acesso físico aos dados do portador do cartão bem como a monitoração por câmeras CFTV, ter normas e procedimentos para permitir os acessos físicos aos ambientes protegidos, gravar as informações e em local seguro e controlável entre outros controles.

Monitorar e testar as redes regularmente

Um programa de monitoração e testes das redes devem ser implementados e executados regulamentes para garantir a segurança do ambiente tecnológico.

Requisito 10 – “Acompanhar e monitorar todos os acessos com relação aos recursos de rede e dados do portador do cartão”.

Mecanismos de auditoria devem ser implementados para monitorar todos os acessos, deve sincronizar o timezone de todos os sistemas e aplicativos do ambiente tecnológico, utilizar IDS (Intrusion Detection System) é altamente recomendável, reter no mínimo por 3 meses os logs para futuras auditorias se faz necessário, bem como outros controles.

Requisito 11 – “Testar regularmente os sistemas e processos de segurança”.

Executar regularmente Scanners de Vulnerabilidade de Redes internos e externos ou após alguma mudança no ambiente se faz necessário. Para redes wireless deve ser analisadas regularmente e verificadas as conexões presentes e o trafego passado. Testes de Invasão internos e externos devem ser executados uma vez ao ano. IDS (Intrusion Detection System) deve ser utilizado no ambiente tecnológico e monitorado o trafego entre as redes.

Manter uma política de segurança das informações

Criar e manter uma política atuante se faz necessário para atender todos os controles apresentados anteriormente, assim garantindo que todos os processos com normas claras e objetivas atendam as demandas de segurança de proteção dos dados do portador do cartão.

Requisito 12 – “Manter uma política que aborda a segurança das informações.”

Deve existir uma política estabilizada, publicada, disseminada, atualizada que atenda todos os requerimentos do PCI DSS. A sua atualização deve ser feita anualmente pelo comitê gestor da empresa e a atualização deve atender todas as atualizações de software e hardware do ambiente tecnológico e físico.

Fica claro que todas as explicações apresentadas aqui é uma pequena parte do que realmente são os doze requerimentos do PCI DSS, desta forma o objetivo é alinhar o conhecimento de todos os profissionais que de alguma forma necessita seguir esse conjunto de regras.

A aplicabilidade desses requisitos pode e deve ser utilizados não somente para atender a proteção das informações do portador do cartão, mas sim elevar o nível de segurança de todas as redes, sistemas e programas das empresas e negócios.

Miopia dos Gestores de Segurança.

Claudio Oliveira — Thu, 16 Jul 2009 13:36:29 GMT

Após anos de experiência na área de Tecnologia e Segurança da Informação, vejo cada vez mais o que podemos chamar de falsa sensação de segurança, isto é os gestores de segurança desconhecem seus problemas e riscos ao negocio.

O desconhecido coloca os gestores em uma zona de conforto onde eles acreditam que os controles e tecnologias aplicadas, estão a contento para suportar e assegurar os negócios das empresas.

Sempre que é executado um levantamento de Gaps de segurança ou uma avaliação de segurança, podemos encontrar diversos riscos desconhecidos pelo gestor, isto ocorre pelo fato que muitos destes riscos nunca foram enumerados ou tratados pelas políticas e normas de seguranças das empresas ou até mesmo essas empresas não têm políticas ou diretrizes para tratá-las.

Ao final dessas atividades grande relatórios são gerados e entregues aos gestores, com diversos riscos que na sua maioria nem sempre são compreendidos por eles, problemas que antes nunca fora observado ou detalhes importantes que ficaram em uma área nebulosa das empresas, aparecem com uma intensidade grandiosa gerando muita preocupação e desconfiança.

Lembro-me que uma vez em uma reunião de apresentação do relatório após um Assessment (Avaliação de Segurança) , o gestor me questionava se todos os riscos apresentados no relatório eram “realmente tangíveis”, o que me deixou extremamente preocupado, pois este gestor estava mais preocupado em diminuir em números os riscos apresentados (pois o relatório seria replicado para sua matriz), do que realmente entender qual era o grau de severidade e gravidade dos mesmos.

Comecei a compreender esse comportamento de uma forma mais racional, pois estava tirando esse gestor de sua zona de conforto, colocando ele em uma posição extremamente delicada, exigindo um planejamento estratégico emergencial de curto, médio e longo prazo.

Para este caso acompanhei todo o processo de levantamento e implantação das correções, pude verificar que o foco do gestor nem sempre era da solução imediata do problema e sim criar um ambiente onde seria possível responder para sua matriz que o problema foi mitigado, não o suficiente para proteger o negócio da empresa e sim gerar um relatório com um Ok para os controles.

Ficou claro que muitas das correções de médio e longo prazo, demandava investimentos, muitos desses não provisionados para o período fiscal e a outra parte a serem aprovados, pelo executivo patrocinador ou comitê gestor de finanças da empresa. Porém parte desses investimentos nunca seria aprovada. Foi recomendado ao gestor de Segurança partilhar a gestão do risco com os mesmos executivos que aprovam o orçamento, pois garantir a segurança dos negócios é responsabilidade de todos os gestores das empresas e não somente o Gestor de Segurança da Informação.

Casos como este é cada vez mais comum no mundo corporativo, os gestores necessitam avaliar com mais freqüência e reconhecer os riscos e ameaças sobre seus negócios. Determinar o tratamento preventivo e corretivo, com forças tarefas mais focadas, elevará a eficácia, eficiência e diminuirá os custos envolvidos para manter os níveis de segurança em patamares aceitáveis.

PCI DSS Check-list versus metodologia.

Claudio Oliveira — Wed, 08 Jul 2009 13:29:23 GMT

Quando surgem novas exigências legais que as empresas devem atender (SOX, PCI, Basiléia, etc...), começa uma nova fase nessas empresas.

Uma fase de profundas mudanças que mexem diretamente no dia a dia de toda empresa e muito mais na rotina de todos os colaboradores, parceiros e fornecedores envolvidos direta ou indiretamente com essas demandas.

Essas mudanças estão sempre acompanhadas de novos processos a serem seguidos e de grandes mudanças de comportamento, dessa forma, surgem os primeiros paradigmas corporativos. Vamos criar procedimentos e processos a serem seguidos, ou melhor, trabalhar na cultura coorporativa, isto é, enraizar as mudanças de forma cultural e racional a fim que todos sigam estes processos e procedimentos de forma mais natural e racional.

Conseguimos verificar nas empresas que todas essas mudanças vêm sempre acompanhadas de uma grande imposição para ser seguidas, ou melhor, a técnica do medo. Se tivermos algum issue ou não conformidade e empresa será punida com perda financeira ou problemas com a imagem coorporativa.

Grandes check-lists são criados para cada área e são cobrados a ferro e fogo pelas áreas de Auditoria ou Segurança de Informação, gerando assim demandas sazonais onde os check-lists são usados somente próximos das datas de auditoria e evidencias são geradas somente para atender exigências da auditoria, a fim de conseguir atender as demandas legais.

Empresas de consultoria na sua maioria vendem seus projetos baseados em horas/homens, isto é, quanto custa disponibilizar meus consultores em X horas para o projeto Y, e dessa forma constroem o seu valor versus o que será entregue para o cliente no final desse tipo de projeto. Dessa forma é criado o que chamo de “menor esforço pelo menor custo possível”. Dessa forma, distorções relacionadas à qualidade e controles são enormes.

Para o PCI Security Standards Council os 12 requerimentos básicos de segurança devem ser seguidos, assim algumas empresas rapidamente criam grandes check-lists e começam aplicá-los sem avaliar alguns pontos muitos importantes como: Cultura Organizacional, infra-estrutura Tecnológica existente, mercado de atuação da empresa, conhecimento técnico dos colaboradores, fornecedores e parceiros da empresa.

Sem essa avaliação prévia desses itens, seguir o check-list será um caminho muito mais árduo e gerador de conflitos altamente destrutivos, com controles temporários (controles que serão seguidos somente nos períodos de auditoria) e falhas de processos, pois são processos e controles totalmente impositivos sem uma razão racional para serem aplicados.

A empresa Tevora South America, por exemplo, utiliza uma metodologia que antes de implementar ou adequar qualquer novo controle em uma empresa, um estudo complementar deve ser elaborado para verificar possíveis distorções processuais ou de infra-estrutura, isto é, verificar possíveis falhas e gaps que possam ocorrer na implementação desses controles ou processos.

Essa abordagem minimiza futuros problemas com auditorias, pois implementar mudanças exige muito mais que simplesmente só comunicar aos envolvidos. Buscamos envolver toda a empresa, parceiros e fornecedores nesse processo de mudança e adequação, de forma que todos auxiliem na obtenção e sucesso da certificação exigida. O check list deve ser uma ferramenta para auxiliar na implementação dessa metodologia e não o produto final de PCI.

Obter um melhor entendimento do ambiente de negócios e tecnológico da empresa ajuda o consultor trazer um valor agregado aos negócios, melhorando a alocação dos recursos.

Uma correta abordagem nos processos de mudanças trará mais eficiência aos resultados, e serão mais aceitos por todos envolvidos nessa cadeia. A certificação vira uma conseqüência como resultado final e não a obsessão irracional que geram grande desgaste e insatisfação.