Escrevi este artigo para falar um pouco sobre PCI, uma vez que não consegui achar muito material em português sobre o assunto. Como de costume, uma versão em PDF também está disponível. Críticas, sugestões e comentários são muito bem vindos.

Muito mais que um padrão Snake Oil

No meio da corrida pelo ouro que movimentou a Califórnia do Século XIX, muitos comerciantes aproveitaram a grande quantidade de moeda circulante para vender um elixir que curava tudo: o Snake Oil. De dedo inflamado a dor de cabeça, o remédio tinha propriedades milagrosas. Ou pelo menos era vendido assim. Com o passar do tempo, o termo entrou para o linguajar norte-americano como uma fraude que promete milagres mas é incapaz de fazer mais que um placebo. O onipresente autor, pesquisador e profissional de IT Security, Bruce Schneier, usou o termo em seu blog ao se referir a forma como alguns produtos de criptografia estavam sendo vendidos. Belas palavras que impressionam um leigo mas ao serem analisadas por um profissional com um mínimo de conhecimento sobre o assunto não passam desta definição: belas palavras.

Os padrões de segurança estabelecidos pelo Payment Card Industry (PCI) Council são referenciados por muitas pessoas desta forma, como um conjunto de regras simplista criado para satisfazer a necessidade de mostrar aos clientes das operadoras de cartão de crédito que seus dados estão sendo protegidos. Esta visão me parece primária e equivocada, pois a adoção de qualquer padrão de segurança pode cair no mesmo erro. Durante a minha carreira já vi empresas de diversos setores implementarem Planos Diretores de Segurança da Informação que deixavam todos os auditores que tinham pouco pouco tempo para fazer o seu trabalho satisfeitos, mas não resistiam a uma análise um pouco mais profunda.

Independente de qual seja o padrão de segurança que a sua empresa adote – ou queira adotar – a forma como o processo é implementado e administrado, importa muito mais do que a quantidade de controles que serão colocados no seu ambiente. Os controles estabelecidos pelo PCI Council tem a vantagem de serem simples, eficazes dentro do escopo ao qual se propõe a abordar e altamente escalonáveis. Este artigo mostra em uma visão geral, como estes padrões nasceram, quais controles são esperados e como a sua empresa pode se alinhar para um processo de certificação.

As origens do PCI DSS

A popularização da Internet e o consequente cresimento do e-commerce multiplicaram de forma exponencial a quantidade de transações feitas pela Internet, gerando somente no Brasil, um crescimento anual que orbita entre 40% a 60%. Em valores mais palpáveis, este mercado movimentou R$ 6,3 bilhões em 2007, com um tíquete médio de R$ 302. E apesar das opções de boleto bancário e débito em conta corrente, o cartão de crédito é a forma de pagamento escolhida pela maioria absoluta dos consumidores. Um cenário impressionante que cria um motivador para o cyber crime em todas as partes do mundo.

A fraude mais comum é o furto de dados de um determinado portador de cartão de crédito e o uso para compras e transferência de valores entre contas. A mídia brasileira publica com frequência a prisão de quadrilhas envolvidas com este tipo de prática, porém um cenário muito mais amplo já está sendo mantido: o comércio de números de cartão de crédito no mercado negro. Uma vez que é muito mais eficaz concentrar a tentativa de furto de dados em um lugar onde exista uma grande quantidade de números de cartão de crédito, para que um cyber criminoso irá perder tempo com um único consumidor se ele pode mirar na base de dados de uma empresa de e-commerce?

Se cruzarmos esta premissa com a quantidade de vulnerabilidades que existem em web sites, está pronta a receita para uma avalanche de fraudes em todo o mundo. E elas estão ocorrendo há quase uma década com números cada vez maiores, uma vez que o crime organizado aprendeu a usar crackers para suportar suas atividades. As fraudes[1] envolvendo informações de portadores de cartão de crédito aumentaram de US$ 1,5 bilhões em 2000, para US$ 3,6 bilhões em 2007, e como mesmo período, o percentual de perdas com fraudes on line caiu de 3,6% para 1,4%, os números deixam claro que já algum tempo era preciso fazer algo para interromper a crescente perda de rentabilidade frente as fraudes, uma vez que o comércio on-line não para de crescer.

Diante deste cenário, as maiores empresas de cartões de crédito – American Express, Discover, MasterCard e Visa – decidiram criar regulamentos para evitar o furto de dados dos portadores de seus produtos e o uso destes em fraudes. O PCI Data Security Standard (DSS) foi criado em 2004 e implementado à partir de 30 de junho de 2005.

Os controles do PCI DSS

Focado em implementar controles de segurança nos componentes da infraestrutura de TI que suportam o fluxo de dados do portador de cartão de crédito, o PCI DSS é formado por um conjunto de práticas que estão presentes na maioria das normas e regulamentações relacionadas à Segurança da Informação.A grande diferença, é que o PCI DSS é focado na proteção de um ativo exclusivo, e foi desenvolvido para impedir a ocorrência de fraudes e outros problemas oriundos do uso inadequado das informações relacionadas ao cartão de crédito.

Composto de doze exigências distribuídas em seis linhas de controles, o PCI DSS apresenta controles de segurança técnica básicos, que devem ser entendidos como uma primeira etapa na construção de um ambiente protegido.

Construa e Mantenha uma Rede Segura

Por mais simples e óbvia que pareça esta prática, uma das maiores portas de entrada para o cyber crime é o uso de contas default e a exploração de parâmetros de segurança fornecidos pelos prestadores de serviços. Usando informações que podem ser obtidas pela Internet, ou exploits de vulnerabilidades conhecidas, os crackers acessam as bases de dados das empresas, capturam a informação e apagam seus rastros.

Nas duas exigências relacionadas a esta linha de controle, o PCI DSS exige que as empresas tenham um firewall protegendo sua rede de dados e nunca caiam no erro apresentado no parágrafo anterior. Os controles se abrem em itens muito específicos descrevendo as configurações mínimas e como proceder na administração das mesmas no dia-a-dia.

Proteja os Dados do Portador de Cartão

Uma vulnerabilidade largamente explorada em tentativas de acesso indevido, é a presença de falhas em bancos de dados decorrentes de configurações inadequadas e falta de cuidado com a modelagem do controle de acesso. A exigência 3 do PCI DSS toca exatamente neste ponto, detalhando como as bases de dados com informações sensíveis – dentro do escopo já citado – devem ser protegidas quando armazenadas.

A exigência 4 completa o ponto, especificando como elas devem ser protegidas em trânsito. Nesta vale uma observação, além do fluxo comum pela Internet que deve ser protegido com Secure Socket Layers (SSL) e similares, a transmissão a ser cuidada inclui redes nem sempre consideradas, como WiFi e GPRS. Um bom trabalho de casa para as empresas que equipam suas forças de vendas com smartphones e similares.

Mantenha um Programa de Administração de Vulnerabilidade

Apesar da exigência 5 determinar algo relativamente comum às empresas, que é o uso e a administração de programas antivírus, incluindo suas atualizações de assinaturas e modo de implementação, a exigência 6 toca em um aspecto constantemente ignorado: o cuidado no desenvolvimento e manutenção de sistemas operacionais e aplicações. A instalação de patches de segurança não é um processo usual, pois mudanças em um ambiente um pouco mais complexo que o padrão considerado pelo fabricante pode simplesmente para um sistema crucial para a empresa.

Como avaliar o que é mais importante em janelas de tempo onde as vendas de uma empresa estão ocorrendo? Parar um servidor para executar a atualização e interromper o processo comercial ou deixar para fazer quando puder? E torcer para esta data existir depois que o stress da situação passar? Indo além no mesmo ponto, em quantas empresas existe um Secure Development Life Cycle (SDLC) integrado ao processo de desenvolvimento de aplicações internas?

São exigências que devem considerar áreas muito além do escopo definido pelo PCI DSS e exigem investimentos em empresas de qualquer porte – e por isso mesmo, estão entre as mais criticadas pelo mercado – mas não passam de práticas de segurança que devem ser utilizadas em qualquer empresa que queira alcançar um nível mínimo de proteção do seu ambiente de TI.

Implemente Medidas Rígidas de Controle ao Acesso

Estabelecer um processo de segregação de funções e o Princípio do Menor Privilégio, são práticas consagradas de administração de empresas para evitar fraudes e abusos de privilégios como os que resultaram na criação da regulamentação Sarbanes-Oxley nos Estados Unidos.

A exigência 7 do PCI DSS segue esta linha, estabelecendo que o acesso aos dados do portador de cartão deve ser concedido somente aqueles que necessitam conhecê-lo para a execução de seus trabalhos.

A exigência 8 estabelece a necessidade de atribuir um único ID par cada pessoa que acesse os sistemas, um princípio consagrado de rastreabilidade. Vale olhar com mais cuidado o texto, pois a abertura dos critérios entra em vários tópicos de controle de acesso, como bloqueio de contas, troca de senhas e autenticação de dois fatores.

A exigência 9 define as medidas de controle de acesso físico aos dados do portador de cartão, dando uma pequena pincelada em administração de mídias de backup e tratamento de descarte de mídias, ainda que não seja muito criteriosa neste último aspecto.

Acompanhe e Teste Regularmente Todas as Redes

As exigências 10 e 11 se completam em um processo de monitoramento contínuo da segurança estabelecida na rede de dados. Enquanto a primeira foca na obrigatoriedade de se acompanhar e monitorar o acesso aos recursos da rede e dados do portador de cartão, a segunda segue na linha de testes regulares de segurança técnica, onde scans de vulnerabilidade externa e penetration tests fazem a simulação de uma tentativa de cracking à partir do ambiente externo.

O monitoramento de acesso citado na exigência 10 trata da existência e administração de vários tipos de logs, tais como os que registram acessos privilegiados, alteração de objetos, processos de autenticação e outros eventos que podem ser utilizados posteriormente para rastrear uma tentativa de quebra de segurança.

A exigência 11 entra em um dos pontos onde a empresa precisa contar com os serviços especializados de um Approved Scanning Vendor (ASV) para executar as atividades de análise externa de vulnerabilidades. Além de ser um ponto de controle onde muitas empresas erram por não manterem uma rotina de testes dessa natureza, é fundamental entender que o processo de scans e pen-tests é novamente focado no escopo do PCI DSS, e não deve ser entendido como um teste de vulnerabilidades baseado nestas práticas.

Mantenha uma Política de Segurança da Informação

A exigência 12 é a única componente desta parte, mas é desdobrada em dez tópicos complementares que especificam exatamente o que é esperado pelo PCI DSS em uma Política de Segurança. Os controles são completamente voltados para Segurança Técnica dentro do escopo pretendido pelo padrão, e assim como a prática anterior, não deve ser confundidos com o desenvolvimento e implementação de um Information Security Management System (ISMS) da ISO 27001.

Um ponto extremamente relevante nesta exigência, é a obrigação dos prestadores de serviços de hosting (ex. Data Center) em aderir a algumas das regras estabelecidas pelo PCI DSS. O texto do padrão é muito claro em informar que “o prestador de serviço de hosting deve atender a todas essas exigências (citadas), assim como todas as outras seções relevantes do PCI DSS….”, isto abre margem a interpretação de que o padrão deve ser aplicado em qualquer local onde os dados do portador do cartão estejam sendo armazenados e/ou transmitidos, e extende a responsabilidade pela proteção a todas as partes envolvidas.

Como Funciona a Aderência ao PCI DSS

A primeira questão a ser respondida é: o quão aderente a empresa precisa estar? O PCI DSS deve ser aplicado a qualquer organização que armazene, processe ou transmita os dados do portador de cartão, desde que o Primary Account Number (PAN) esteja dentro deste escopo. E ele normalmente está.

É necessário então classificar em qual nível de aderência a empresa deve ser incluída, o que irá determinar o tipo de trabalho de adequação necessário e as medidas de manutenção da aderência ao decorrer do tempo. O gráfico abaixo mostra o ecosistema estabelecido pelo PCI Council, onde irei abordar somente o processo de certificação com o PCI DSS.

A Classificação dos Comerciantes e Processadoras

O PCI DSS define cinco modelos de validação[2] para a aderência ao PCI DSS, baseados em como a empresa utiliza os dados do cartão de crédito.

Para cada modelo, um Self Assessment Questionnaire (SAQ) é mantido e deve ser utilizado para a validação da necessidade de aderência, onde os controles podem ser melhor entendidos, avaliados e sua aplicabilidade verificada.

• SAQ 1: Estabelecimentos de cartão ausente (e-commerce ou transações pelo correio ou telefone), todas as funções de dados de portador de cartão executadas por terceiros. Esta categoria nunca se aplica a estabelecimentos com vendas frente a frente.
• SAQ 2: Estabelecimentos apenas com máquina de decalque e sem armazenamento dos dados do portador de cartão.
• SAQ 3: Estabelecimentos de terminal independente tipo dial-up, sem armazenamento dos dados do portador de cartão.
• SAQ 4: Estabelecimentos com sistemas de aplicativo de pagamento conectados à Internet, sem armazenamento dos dados do portador de cartão.
• SAQ 5: Todos os outros estabelecimentos e todos os prestadores de serviço definidos por uma marca de pagamento como sujeitos a preencher um SAQ.

Após entender como a empresa deve avaliar sua necessidade de aderência, o processo de validação de controles pode ser iniciado através da análise de atendimento a cada um dos requerimentos estabelecidos pelo PCI DSS.

Algo que é interessante para as empresas neste cenário, é aproveitar este momento para entender o seu nível de classificação dentro dos critérios de quantidade de transações estabelecido pelo PCI Council, e estimar o custo de manutenção da aderência para curto, médio e longo prazo. Estes níveis seguem os critérios estabelecidos pela VISA e MasterCard na classificação de seus clientes pela quantidade de transações efetuadas em um período de 12 meses, e também são aplicáveis às Processadoras:

Da Análise de Aderência ao ROC

Após avaliar em qual nível de atendimento aos requerimentos a empresa está inclusa, o processo de aderência pode ser iniciado. Existem diversas formas de começar este trabalho, e possivelmente uma empresa especializada poderá ajudar.

Neste ponto, começa a necessidade de estimar até onde uma empresa precisa de ajuda externa para estar aderente ao PCI DSS. As consultorias especializadas são autorizadas pelo PCI Council a atuarem em dois escopos diferentes:

• Qualified Security Assessor (QSA): São empresas autorizadas a prestar serviços de auditoria na aderência ao PCI DSS – chamados no jargão relacionado de On-Site Data Security Assessments – processos de Gap Analysis com o padrão e demais serviços de consultoria relacionados.
• Approved Scanning Vendor (ASV): São empresas autorizadas a prestar serviços de application vulnerability scans e penetration tests no escopo do PCI.

Ao considerar o suporte destes dois modelos de trabalho especializado na obtenção da aderência ao padrão, as empresas devem avaliar alguns pontos de custo/benefício que irão variar de acordo com cada mercado, tipo de empresa e tamanho do escopo onde o PCI DSS é aplicável.

Primeiro Passo: A Análise de Aderência

O processo de comparação dos controles existentes com os requerimentos do PCI DSS é conhecido como gap analysis e pode ser feito por qualquer pessoa que tenha um conhecimento mínimo de segurança. O que deve ser feito é fazer o download do PCI DSS, entender os controles estabelecidos e mapear o quão aderente a empresa está.

Os próprios documentos disponíveis no web site do PCI Council podem ser usados neste processo. Além do padrão estar disponível em várias línguas, existe um FAQ bastante completo, e documentos de suporte para diversas atividades. Eu recomendo que ao fazer um gap analysis, a empresa use o mesmo documento considerado para o On-Site Data Security Assessment.

Este documento apresenta os controles em uma matriz de aderência bastante útil, simplificando o processo e ajudando a não esquecer nenhum dos controles apresentados.

Usar uma empresa especializada em Segurança da Informação – seja um QSA ou não – para ajudar neste processo é uma questão de avaliar se a equipe da empresa tem as competência, a experiência e o tempo para esta atividade.

As maiores vantagens de ter o suporte de alguém com experiência neste tipo de atividade, é não repetir os erros ocorridos em outras empresas e poder contar com o conhecimento necessário para fazer o que é recomendado por todas as consultorias da área: reduzir o fluxo dos dados do portador do cartão ao mínimo possível.

Isto permite que a aderência ao PCI DSS seja menos custosa e a manutenção dos controles mais simples, barata e eficaz. Especialmente para empresas de médio e pequeno porte, esta recomendação pode fazer uma grande diferença.

Segundo Passo: Implementando os Controles

Como defendi no início deste artigo, o PCI DSS tem a vantagem de manter controles simples, eficazes dentro do escopo ao qual se propõe a abordar e altamente escalonáveis. Quando se tem o resultado do gap analysis, é possível analisar não só as necessidades de implementação de controles, como ainda ter uma boa perspectiva das deficiências da empresa em relação à Segurança da Informação.

Como os controles estabelecidos pelo PCI DSS podem ser aplicados a toda a empresa, é bem possível que as atividades para atender a necessidade de aderência caiam em uma das falhas mais comuns em qualquer empresa[3].

A solução recomendada é corrigir as vulnerabilidades existentes e desenvolver os controles exigidos pelo padrão em toda a organização. Claro que isso custa dinheiro e requer um esforço que talvez não esteja disponível, e é aí que a escalonabidade do PCI DSS pode ajudar.

Quando a aderência é o motivador para o desenvolvimento dos controles, é possível trabalhar dentro do escopo requerido pelo PCI DSS e posteriormente ampliar a aplicabilidade para os demais componentes da empresa.

Especialmente quando se fala de Controle de Acesso e Política de Segurança, é muito provável que seja necessário implementar em quase toda a empresa para atender aos requerimentos do padrão, o que pode ser usado para elevar o nível de segurança de uma forma geral.

Terceiro Passo: A Auditoria

Depois de implementar os controles faltantes e atender aos requisitos do PCI DSS, é necessário fazer uma auditoria que ateste a presença e eficácia dos mesmos na proteção dos dados do portador de cartão. O processo novamente depende do posicionamento da empresa dentro das categorias definidas pelo PCI Council.

Os Comerciantes classificados nos Níveis 2, 3 e 4 e as Processadoras classificadas no Nível 3, podem fazer a auditoria através do PCI Self-Assessment Questionnaire, o que não requer nenhuma ajuda externa e pode ser feito pela equipe da própria empresa nos mesmos moldes apresentados para o gap analysis.

Os Comerciantes classificados no Nível 1 e as Processadoras classificadas nos Níveis 1 e 2, precisam obrigatoriamente contratar um QSA para fazer a auditoria.

Existem algumas discussões em andamento, na qual é defendida a posição de um grupo de auditoria interna da empresa ter a “autorização” para fazer o On-Site Data Security Assessment. Em caso de dúvidas nesta questão, a melhor coisa é questionar diretamente o PCI Council.

Ao final, tendo todos os controles presentes, é necessário enviar para a bandeira de cartão de crédito ou o banco emissor – varia caso a caso, país a país, mercado a mercado – uma cópia do PCI Self-Assessment Questionnaire ou do Report on Compliance (ROC) para assegurar o atendimento aos requerimentos e a certificação de aderência.

Quarto Passo: A Manutenção

Em qualquer processo de aderência a um determinado padrão – seja de segurança, qualidade ou qualquer outro mercado – a manutenção é a parte mais complicada. Além de ser necessário inserir na rotina da empresa os controles requeridos, existe toda uma dinâmica de negócios que pode ameaças a manutenção da aderência em decisões difíceis de serem tomadas.

No caso do PCI DSS, este processo me parece o mesmo independente do nível de classificação do Comerciante ou Processadora, uma vez que a manutenção dos controles é o desafio, e provar para o PCI Council, bandeiras de cartão e bancos emissorres que a empresa está aderente, é só mais um processo. Os modelos estabelecidos são:

• On-Site Data Security Assessment uma vez por ano e Network Scans a cada trimestre para os Comerciantes no Nível 1 e Processadoras nos Níveis 1 e 2.
• PCI Self-Assessment Questionnaire uma vez por ano Network Scans a cada trimestre para os Comerciantes nos Níveis 2, 3 e 4 e as Processadoras no Nível 3.

A justificativa do PCI Council para os dois modelos, está no tamanho da estrutura dos Comerciantes e Processadoras, e na divisão da análise dos controles em uma perspectiva interna (a auditoria ou o self-assessment) e externa (os network scans).

É comum ouvir críticas sobre a eficiência deste processo, e elas são muito relevantes. Certamente uma auditoria baseada em repostas a um questionário e requisição de evidências a um cliente, não mostra de forma completa como está a segurança dos controles e processos de um ambiente. Muito menos um network scan ou penetration test por si só são as ferramenta ideais para analisar as vulnerabilidades que podem ser exploradas à partir de um acesso pela Internet.

Como na aderência a qualquer padrão, a qualidade e eficiência dos controles vai depender de como a empresa se porta em relação à Segurança da Informação como um todo. Existem motivadores financeiros para isso, como os casos da TJX, Bank of America, Morgan Stanley e Citibank exaustivamente citados como exemplos de falta de aderência ao PCI DSS com resultados desastrosos.

A Questão da Obrigatoriedade

O PCI Council estabelece alguns prazos para que os Comerciantes e Processadoras adotem o PCI DSS, porém a obrigatoriedade depende de como as bandeiras de cartão tratam o assunto, o que também varia de acordo com cada mercado.

Em alguns países existem leis que estabelecem regras de proteção para os dados de consumidores e privacidade em geral, e o PCI DSS acaba sendo somente mais um padrão a ser seguido. Em outros, as bandeiras de cartões e bancos obrigam os comerciantes a cumprirem os requerimentos ou serem multados e até perder o contrato comercial que garante o uso desta forma de pagamento. Tudo é uma questão de como o mercado se comporta.

Porém, manter a empresa aderente ao PCI DSS é parte do bom senso de proteger as informações dos portadores de cartão e evitar todos os impactos decorrentes de um acesso e uso indevido destes dados. Pessoalmente, eu vejo no mínimo quatro motivos básicos para uma empresa adotar este padrão:

• Permite que as vulnerabilidades e possibilidades de melhoria mais simples sejam identificadas, um modelo básico de segurança implementado à partir deste resultado e posteriormente ampliado para estabelecer uma estratégia de proteção integrada aos demais dados e informações considerados importantes;
• Permite proteger as informações dos clientes, o que além de evitar uma exposição desnecessária da empresa em caso de vazamentos – e os consequentes processos que podem ser movidos na maioria dos países – pode ser usado como ferramenta de marketing para diferenciar a empresa de seus concorrentes, e
• É simples e escalonável, o que o torna muito mais fácil de ser vendido internamente em uma empresa que a aderência a processos e padrões mais complexos como os da família ISO 27000.

Conclusão

Como citei no começo deste artigo, a aderência ao PCI DSS pode ser considerada um snake oil por alguns setores, mas se olhada com um ponto de vista mais otimista, é o primeiro passo no aumento da proteção a qualquer ambiente. Os controles são simples, altamente escalonáveis e podem ser usados por praticamente empresas de qualquer porte e mercado.

O que sempre irá determinar o nível de proteção é o quanto a gerência da empresa dá importância para isso. Sempre existirá uma queda de braço entre a Segurança da Informação e o atendimento às necessidades de negócio da empresa, e o grande desafio não muda: é equilibrar como estes dois pontos devem ser tratados.

O mesmo se aplica ao PCI DSS, a implementação deve ser equilibrada e atender ao que a empresa quer como produto final dos seus negócios (lucro, correto?) ao invés de ser colocado como mais um custo que “tem que ser endereçado” pois é uma “exigência” do mercado.

A aderência ao PCI DSS é uma excelente escolha quando a empresa não tem um padrão de segurança implementado e precisa de algo para começar a proteger seu ambiente. Para aquelas que já possuem aderência a uma linha de controles, é uma oportunidade de alinhar o que está implementado com o que pode ser melhorado. As empresas ganham das duas formas.

Sites Relacionados

Alguns dos sites abaixo relacionados são mantidos por empresas que prestam serviços relacionados aos requerimentos do PCI Council, e podem ter um forte apelo comercial. De qualquer forma, todos apresentam informação de qualidade sobre o padrão e facilitam o entendimento do processo de uma forma geral.

· American Express Data Security

· Discover Information Security & Compliance

· JCB International Security

· MasterCard Site Data Protection Program

· PCI Standards Overview

· Visa Cardholder Information Security Program

· PCI Standard.com

· PCI Compliance Guide

· PCI Answers

Pesquisa mostra que o maior culpado pelas falhas de segurança não é mais o funcionário

A mudança do paradigma

Durante muito tempo a única pesquisa de referência em Segurança da Informação era o documento anual “Computer Crime and Security Survey” publicado em conjunto pelo Computer Security Institute e o FBI desde 1997. Nos cinco primeiro anos, em média 48% dos eventos relacionados à falhas de segurança foram atribuídos ao “inimigo interno”, funcionários que causavam problemas por desconhecimento, abuso de privilégios e mesmo por pura vontade de prejudicar suas organizações.

Nos anos seguintes, este percentual não variou muito e boa parte do mercado assumiu uma unanimidade: o grande culpado pelas falhas de segurança é o funcionário. Houve então um direcionamento para o desenvolvimento e enforcement de políticas de segurança, sessões de treinamento e capacitação, adoção de ferramentas automatizadas e uma série de outros processos que tiveram o seu papel em criar ambientes mais seguro. Só foi esquecido de combinar isso com os crackers.

O que eu vi em muitos lugares foi um completo esquecimento da base da segurança, a adoção de processos seguros no planejamento dos sistemas, desenvolvimento de aplicações, instalação de componentes e claro, na manutenção de tudo isto em cenários onde a velocidade do mercado acaba atropelando a forma como os sistemas automatizados suportam os processos de negócio. Investiu-se muito em gestão de riscos e quase nada em práticas mais simples e bastante eficazes.

O resultado está bem claro no relatório 2008 Data Breach Investigations Report, publicado pela Verizon Business. Em mais de 500 casos investigados pela empresa, 75% dos vazamentos de dados foram executados por ameaças externas em múltiplas combinações de eventos, mas com um dado impressionante: 90% das vulnerabilidades exploradas com sucesso por estes ataques, tinham correções disponíveis pelo menos seis meses antes do problema ocorrer.

Continuando nos percentuais apresentados, 87% dos problemas poderiam ter sido evitados com a adoção de controles de segurança adequados, uma vez que a maioria dos ataques foram oportunistas e utilizaram brechas existentes nos sistemas para acessar dados que estavam em locais inadequados. Em uma primeira análise, parece que as empresas estudadas pela Verizon Business eram extremamente amadoras, mas não é bem assim.

É necessário mudar a postura

É fundamental entender e aceitar que a segurança ainda não é uma prioridade para as empresas, e infelizmente este quadro parece nunca mudar. Quantos projetos não tem as práticas de proteção preventiva cortadas durante o planejamento por serem consideradas dinheiro perdido ou acréscimo de tempo desnecessário? Quantos gerentes de TI não se submeteram a uma ordem expressa para alterar uma base de dados sem passar pelo processo de Change Management porque o produto “tem que estar na rua hoje”?

Este é o cenário da maioria das organizações, e por mais que as pesquisas mostrem, parece que é mais fácil culpar a “mão invisível do cracker” ou trocar a equipe “incompetente” que deixou isso acontecer. Que não existe segurança absoluta é óbvio, mas deixar de seguir um plano mínimo de proteção dos dados e aceitar falhas de segurança que poderiam ter sido evitadas em 90% dos casos com um processo simples e de baixo custo beira a irresponsabilidade.

Navegando um pouco mais no relatório, são apresentados dados sobre a causa de 57% dos problemas: os parceiros de negócio com suas conexões à empresa atacada e seus componentes que não seguiam critérios adequados de proteção. Possivelmente ocorreram problemas similares a coisas que já vi como rotina em alguns lugares, uma conexão direta entre as redes de duas empresas – por fora do firewall – porque era necessário “suportar o negócio e ia levar muito tempo pedir a abertura de uma porta”.

As recomendações de melhoria do relatório não fogem do que sempre recomendamos a nossos clientes como boas práticas de segurança técnica, mas que de nada adiantam sem uma mudança de postura em relação à segurança, que tomei a liberdade de incluir em meus comentários para cada tópico sugerido.

Alinhamento de Processos e Políticas

O relatório aponta que em 59% dos casos, a organização vitimada contava com uma Política de Segurança estabelecida, mas que não era efetivamente cumprida. Neste caso, não existe solução técnica completa, pois processos e aplicações de enforcement estão sujeitos a erros e omissões. O que eu recomendo é que a política seja revista e modificada para equilibrar as necessidades de negócio da organização com suas premissas de proteção. Depois disso, é implementar os procedimentos e manter um processo de monitoramento ativo, o que é abordado mais adiante.

Primeiro o essencial e depois o ótimo

De todas as recomendações, eu achei essa a melhor de todas. Como 83% das brechas foram exploradas em processos de baixa e média dificuldade, e 85% dos ataques foram oportunistas, fica claro que faltou completar a lição de casa. Voltando a um tema que abordei em um artigo sobre malware, existem guias de configuração segura disponíveis em várias fontes confiáveis na Internet.

Basta fazer o download, ler, usar e continuar usando. O problema que vejo com mais frequência é uma boa implementação desta prática e uma péssima manutenção, o que deixa o ambiente vulnerável novamente em pouco tempo. Recomendo que a implementação seja feita uma parte da equipe e pessoas diferentes fiquem responsáveis por analisar com frequência se as configurações estão sendo mantidas como esperado.

Proteger as conexões com parceiros de negócio

Como 39% das falhas foram originadas nesta fonte, a recomendação é simples: aumentar a proteção em conexões com parceiros de negócio, o que pode ser feito dentro e fora do seu ambiente. Além de manter controles lógicos nestas conexões (ex. Firewall e IDS), é recomendado que os parceiros de negócio sejam periodicamente auditados para garantir o cumprimento de práticas mínimas de segurança em seus ambientes. Isso não é aceito com muita simpatia por algumas empresas, mas se existe um negócio em conjunto, a proteção deve seguir este mesmo conceito, pois as perdas também poderão atingir ambos os lados.

Criar um Plano de Retenção de Dados

Como 60% das brechas envolveram dados que a vítima não sabia que estava no sistema, a recomendação de criar um processo de retenção de dados (na minha opinião, classificação de informação) é fundamental. Este tópico pode ficar bastante complicado, mas existem processos simples que podem ser utilizados para caminhar nesta direção de forma eficaz:

• Classificar as informações em importante para o negócio e descartável. Claro que é simplista e depois pode evoluir para o confidencial/restrito/público ou algo assim, mas lembre-se da segunda recomendação: primeiro o essencial e depois o ótimo.
• Restringir o fluxo de dados, como é recomendado no PCI DSS, pois você consegue estabelecer um modelo de proteção eficiente e com uma excelente relação custo benefício. Em termos práticos, se uma informação tem que estar no ERP da sua empresa, impeça seus usuários de manter planilhas com uma cópia de tudo “porque é mais fácil”.
• Quando a informação tiver que ser descartada, tenha certeza de que isto ocorra. Use ferramentas de degaussing para limpar dados de computadores que estão na sua empresa e os que são descartados, lembre-se que boa parte das notícias de vazamento de dados nos EUA incluem notebooks e hard disks usados e uma  venda no E-Bay.

Monitorar os Logs de Eventos

De acordo com o relatório, 82% das brechas podiam ser identificadas pelas empresas antes de acontecerem. Claro que revisar logs de eventos é uma tarefa chata e que beira a insanidade, mas existem ferramentas de IDS e IPS que podem dar uma boa ajuda neste processo. Porém, instalar e deixar rodando é algo que vejo acontecer e dá a velha sensação de segurança que não existe, as ferramentas devem ser administradas por pessoas capacitadas e dedicadas a tarefa.

Além disso, é fundamental criar um plano de resposta a incidentes como complemento, mais uma recomendação do relatório. Este processo permite que a empresa não só identifique possíveis tentativas de acesso não autorizado e vazamento de informações, como também define que ações devem ser tomadas em cada caso. Isto inclui o relacionamento interno e externo, tal como o contato com a política, advogados e outros profissionais especializados que devem ser acionados.

Conclusão

Trabalhar com estes processos é parte comum de qualquer conjunto de boas práticas em Segurança da Informação, mas os resultados do relatório deixam claro que a situação em algumas empresas não é esta. Tratar as práticas de segurança como um gargalo, um problema com que se deve conviver ou algo que se faz para agradar os auditores, é uma abordagem ingênua e irresponsável desde que os computadores começaram a suportar os processos de negócio.

É fundamental ter uma mudança de postura e entender que a segurança é mais um processo que suporta o seu negócio, e deve ser tratado como tal. Os processos recomendados pelo relatório não são complicados e podem custar muito menos do que você imagina. Como faria em qualquer análise, que tal olhar o custo x benefício de um vazamento de informações contra estabelecer a segurança como parte do seu dia-a-dia?

Trabalhando em dois fuso horários me sobra pouco tempo para atualizar o blog, mas há algumas semanas publiquei um artigo na Antebellum sobre malware e a atitude das empresas diante da evolução dessa encrenca. Segue o texto abaixo, e como de costume, uma versão em PDF está disponível na página de documentos.

Já tem algumas semanas que uma notícia curiosa foi publicada em vários meios de comunicação: o juiz Mário Jambo, da 2ª Vara Criminal da Justiça Federal do Rio Grande do Norte, concedeu habeas corpus a três crackers presos pela Polícia Federal. A liberdade provisória determina que eles leiam obras clássicas, façam um resumo para cada livro, se matriculem e freqüentem assiduamente uma escola, além de estarem proibidos de usar computadores.

Não consegui encontrar dados suficientes para entender porque o juiz em questão tomou uma decisão tão curiosa, que me parece bastante adequada para adolescentes que foram pegos fazendo alguma bobagem. Tendo em vista que eles foram presos durante a Operação Colossus, cujo objetivo era desarticular uma quadrilha especializada em furto de senhas de correntistas de bancos e falsificação de cartões de crédito, a decisão me parece mais irresponsável do que curiosa.

Prefiro pensar que o juiz em questão não estava bem informado sobre o impacto que o malware tem causado para a sociedade e como a motivação criminosa há muito já substituiu a pura curiosidade intelectual de quem pratica estes atos. Afirmo isto com base em várias pesquisas que circularam recentemente, tais como o Boletim de Segurança 2007 da Kaspersky Lab (www.kaspersky.com) e os documentos publicados pelo Panda Labs (www.pandalabs.com). Ambos são unânimes em demonstrar que essa tendência ganhou força em 2007 e não parece mudar nos próximos anos. O motivador dos eventos que envolvem quebra de segurança é o mesmo: cibercrime.

O volume das perdas

Os números são bastante relevantes. Além dos resultados da 12th Computer Crime and Security Survey publicada este ano pelo CSI (www.gocsi.com) mostrarem que a perda média anual das empresas participantes com cibercrime passou de US$ 168 mil para mais de US$ 350 mil, somente nos EUA as projeções para 2007 passam de US$ 105 bilhões. O grande problema de se calcular com mais precisão o quanto é perdido com o cybercrime está na capilarização dos ataques e na grande diferença utilizada pelas autoridades para calcular a estatística referente. Mas que é um valor elevado e que cresce anualmente, isto é um fato.

A pesquisa do CSI fala em um total de quase US$ 67 milhões, e eu não consegui achar em nenhum lugar o volume de perdas colaterais. Mas imagine o custo envolvido somente em duas situações comuns à maioria das pessoas que usam a Internet como canal de acesso a serviços e produtos:

• Se você vai comprar um produto em uma loja on-line, que passa por um risk assessment regular, têm ferramentas de segurança implementadas e uma equipe de resposta a incidentes, quem será que vai pagar este custo?
• Sua conta bancária está protegida por criptografia em vários sistemas, o acesso ao Internet Banking requer um cartão de códigos variáveis, no back office existem processos de Intrusion Detection Systems, quem será que vai pagar este custo?

Como você já deve ter imaginado, o custo com a proteção é repassada para o cliente, assim como a alta do trigo aumentou o preço do pão que você come no café da manhã. Este custo, caro leitor, é impossível de ser calculado e certamente ultrapassa em muito os valores estimados pelas pesquisas disponíveis. No final das contas, a verdade é que o aumento do malware e o direcionamento para o cibercrime incrementa a demanda por proteção, onera as empresas e este custo passa a fazer parte da composição de preços de vários segmentos. E como podemos reduzir o impacto deste problema em nossos bolsos?

A solução é uma responsabilidade direcionada para a Área de Segurança da Informação?

De forma alguma. O aumento dos casos, abrangência dos ataques e interesse criminoso é uma evolução natural do mercado, uma vez que o e-commerce e outros setores que fazem uso intenso de tecnologia crescem a taxas incríveis, e dois componentes se mantêm: empresas que não consideram segurança como parte dos seus negócios e profissionais que desconhecem as boas práticas em suas atividades.

Falando das empresas, minha experiência de mais de 10 anos no mundo corporativo mostrou uma coisa: as empresas estão interessadas em resultados imediatos e em como isto pode reverter em benefício delas. Até aí, nada demais, pura lei da sobrevivência. O problema é que até hoje a segurança é vista como um gargalo nos projetos de TI, e dificilmente como parte integrante do processo. Sempre que existe um custo ou um esforço da equipe em implementar os processos de segurança em um projeto, a cara feia do gerente de projeto e a reação imediata de tentar reduzir ambos, mostra que o desconhecimento ainda é uma constante.

Se onde você trabalha não é assim, parabéns, a sua empresa é uma das poucas que já estão com um nível de conscientização elevado, mas levando em consideração a pesquisa do CSO no mercado norte-americano (com o qual o nosso regula bastante), onde menos de 1% das empresas participantes vão investir mais do que 22% do orçamento em segurança em conscientização, esta encrenca está longe de terminar.

Da parte dos profissionais, além do resultado citado no parágrafo anterior também incluí-los, existe uma resistência incrível em adotar processos simples de segurança por parte das pessoas. E pelo que está apresentado no relatório Gartner’s Top Predictions for IT Organizations and Users, 2008 and Beyond: Going Green and Self-Healing, isto vai piorar se não tomarmos uma attitude agora.
De acordo com este documento, as empresas estão tomando suas decisões relacionadas a estratégia de TI cada vez mais com base no que os consumidores – ou clientes – querem.

E como boa parte dos CEOs e CIOs tomam decisões com base em documentos deste tipo, a recomendação do Gartner de “Estabelecer iniciativas de comunicação e colaboração entre os usuários e os tomadores de decisão em TI quando selecionarem novas tecnologias e serviços” deve ser entendida como um motivador para mudar a postura, e mudar agora.

Quanto custa combater o malware?

Além dos passos básicos de instalar ferramentas de segurança adequadas a cada ambiente – muitas das quais Open Source e de excelente qualidade – existem documentos públicos que devem ser usados por qualquer empresa como parte de seus processos de negócio, e não de TI ou Segurança da Informação.

O Open Web Application Security Project (www.owasp.org) é um excelente começo. São projetos, ferramentas e guias de implementação que estão disponíveis a distância de um clique de mouse. O OWASP Top 10 mostra as vulnerabilidades mais comuns em web site, e para cada, mostra como o processo de proteção deve ser conduzido. Ferramentas aplicáveis a qualquer ambiente que tenha frameworks baseados em J2EE, .NET, LAMP, Cold Fusion, Struts, Web Services, IIS, WebSphere, WebLogic ou Tomcat têm guias de proteção já publicados e podem ser usadas por pessoas que tenham conhecimento técnico das tecnologias, e não necessariamente de segurança.

E se o problema for na parte processual, o NIST (http://csrc.nist.gov) tem disponíveis mais de 100 documentos que cobrem desde a configuração de servidores até o estabelecimento de um programa de métricas. Basta ler e usar as instruções, que uma vez colocadas podem ser gerenciadas através de metodologias também disponíveis … de graça.

Se o problema é a língua, você deve aprender inglês rapidamente, porque a maioria absoluta dos recursos está neste idioma. Mas no Brasil temos boas iniciativas também, que tal começar lendo o material publicado pelo CERT.BR (www.cert.br)? Lá você irá encontrar listas de ferramentas, práticas profissionais e um documento de conscientização excelente, a Cartilha de Segurança para Internet publicada em http://cartilha.cert.br.

É de graça e ninguém usa?

Se fosse simples desta forma o problema estava resolvido, mas para concluir temos que voltar ao tópico “falta de conscientização”. Em um momento onde o buzzword da hora é GRC (Gestão, Riscos e Compliance), vejo empresas buscando padronizar seus processos, documentar o que é feito e ficarem cada vez mais alinhadas às boas práticas e padrões de excelência em gestão de risco. É sensacional ver como nosso mercado se transformou nos últimos anos, e finalmente chegamos ao campo da gestão nas organizações.

Mas de um modo geral, será que as empresas que estão investindo em tudo isso já fizeram o dever de casa e protegeram sua infra-estrutura de TI? Pelos resultados das pesquisas e as notícias da mídia, não. E ainda assim, recursos são alocados para todo e qualquer ferramenta de gestão de riscos, e dificilmente para aquele baseline que deveria proteger a organização.

A minha sugestão é que você, caro leitor, comece a mudar este cenário. Organizações como a ISSA, OWASP, ISC2 e outras têm uma representatividade pífia no Brasil porque a própria comunidade não se envolve. Sei que todos nós temos nossos trabalhos, famílias, lazer, mas participar de algo que será benéfico para nosso mercado também é trabalho, com remuneração a longo prazo e benefício para todos que participam desta cadeia de valores.

É necessário participar, escrever artigos, publicar trabalhos, pesquisar, se envolver e usar tudo isto em prol da comunidade. Os resultados serão excelentes para todos, afinal o uso de recursos de TI faz parte da vida comum à boa parte da nossa sociedade, inclusive o juiz Mário Jambo que poderá entender o que um cracker faz para ganhar dinheiro.

Em tempo de ROSI, GRC, e outras buzzwords, resolvi escrever alguns artigos sobre um básico que muitas vezes é esquecido: a segurança técnica dos componentes da infra-estrutura de TI. Como de costume, o artigo abaixo está disponível na área de documentos do meu blog, boa leitura.

Em qualquer mercado, sempre existe uma buzzword que toma a mídia especializada e as conversas dos profissionais nas rodas de bate-papo e início de reuniões. Nos últimos meses, o conceito de Governança, Risco e Compliance (GRC) tem aparecido como uma das principais iniciativas em Segurança da Informação, onde um framework muito bem estruturado, ajuda as organizações a manterem o risco em seus ambientes dentro de níveis toleráveis por quem paga a conta. Isso é sensacional, e me deixa satisfeito de ver que a especialização que escolhi como carreira, finalmente assume um papel estratégico.

Porém, existe uma base que muitas vezes é esquecida e até desprezada pelas empresas e profissionais que cuidam dos seus processos de segurança: a segurança técnica. Apesar de ser a parte mais fundamental para a manutenção de um ambiente seguro, este componente é continuamente colocado como item de segunda linha, ou que não precisa de pessoas especializadas para ser adequado e administrado. Isto não é uma opinião pessoal, existem fatos que deixam claro o quanto precisamos melhorar neste aspecto.

A Repetição do Erro

Focando somente em vulnerabilidades em Aplicações Web, os resultados do OWASP Top 10 mostram que apesar de ter obtido em 2007 um crescimento de espantosos 43% em relação ao ano anterior e ter gerado mais de R$ 6 bilhões somente no Brasil, a “cara” do comércio eletrônico é mantida de forma quase amadora. Um relatório publicado recentemente pela consultoria White Hat Security, concluiu que 90% dos web sites estão vulneráveis a ataques diversos.

Este número pode até mesmo ser um exagero ou uma tentativa de FUD, mas que tal analisarmos os resultados do OWASP Top 10 2007 que variam pouco desde 2004? A tabela abaixo deixa claro que pouca coisa mudou em três anos, e vulnerabilidades já conhecidas e com processos corretivos publicados em diversas fontes na Internet, simplesmente não são corrigidas.

Além do que está apresentado na tabela, existem várias outras vulnerabilidades que são facilmente exploradas por worms, crackers amadores e script kiddies. E as consequências podem ir desde uma simples “derrubada” no web site da organização por algumas horas, até o acesso e a modificação de dados de clientes e/ou parceiros comerciais, como pode ocorrer em alguns ambientes na exploração do Cross Site Scripting (XSS) ou do SQL Injection, que não figura no OWASP Top 10 mas é extremamente comum.

O Fator Humano

Quando olhamos uma outra fonte confiável de informação sobre vulnerabilidades, podemos concluir que o problema é gerado não só pela falta de cuidado dos fabricantes em lançar produtos com configurações padronizadas que não são obrigatoriamente alteradas pelos seus clientes, e manter a odiosa prática de senhas padrão para quase tudo. Somado a isto tudo, temos os técnicos que não configuram de forma adequada os sistemas pelos quais são responsáveis, e os usuários desta infra-estrutura que por diversos motivos falham em seguir procedimentos de segurança, estejam estes estabelecidos ou não.

Os dados apresentados no SANS Top-20 2007 Security Risks deixam claro que esta minha afirmação está longe de ser uma conjectura. Web browsers vulneráveis a spoofing e scripts maliciosos, aplicações de escritório que oferecem muito mais que um usuário comum precisa e saem de fábrica carregadas de furos de programação, sistemas operacionais que precisam de correções sucessivas. A lista é longa, e quase todos os items estão diretamente ligados à falta de cuidado com a Segurança Técnica.

Mas antes de apontar o dedo e culpar os fabricantes, técnico e usuários, é preciso entender a causa do problema e os motivos que levam estas listas a não se alterarem com o passar dos anos. Estamos trabalhando da forma certa, quando o assunto é manter o ambiente com um nível de risco aceitável? A resposta é não. Estamos fazendo o que é necessário para os negócios andarem, e isto não necessariamente significa que eles fiquem seguros.

Quantos projetos de TI você conhece que levaram a sério a etapa de avaliar a necessidade de controles, alocar recursos para que estes sejam comprados/desenvolvidos/implementados, e um processo de auditoria independente para revisar o produto final? Da minha parte, posso afirmar que de cada dez, talvez um pudesse ser encaixado nesta categoria. E você?

Buscando Alternativas

A causa me parece muito clara, infelizmente ainda não existe na maioria das organizações o entendimento do que é segurança, e como ela pode ser atingida de forma estruturada. Existem pressões para o sistema de vendas ficar pronto, para o billing atender as mudanças de preço, para o CRM incluir novos cadastros, mas e para que tudo isso funcione com estabilidade? Pressões para um plano de continuidade fazer parte do processo, para o código das aplicações ficar seguro contra ataques ou ainda para simplesmente treinar as pessoas a usarem os recursos de forma certa, existem?

Manter o ambiente com um nível de segurança aceitável significa envolver toda a organização no processo, incluir uma cultura “segura” na cabeça das pessoas, ter o apoio do corpo executivo. Isso é totalmente correto, mas é difícil de conseguir rapidamente não só pela resistência natural que existe, mas também pela falta de priorização que você vai encontrar e pela dificuldade de conseguir fundos para isto.

Porém, o primeiro passo de garantir a presença de controles de segurança técnica, é mais rápido, mais simples e envolve muito menos gente. Se você trabalha em uma empresa de pequeno ou médio porte, talvez a sua dedicação e um apoio mínimo da sua chefia sejam suficiente para mudar as coisas. Existem empresas especializadas em segurança técnica, como a minha, e existem ainda recursos na Internet que custam só o seu tempo de ler, entender e aplicar.

OWASP

O OWASP (Open Web Application Security Project) é uma iniciativa formidável que congrega pessoas de todo o mundo em torno de um só trabalho: criar e disponibilizar práticas de segurança técnica que possam ser usadas para criar um ambiente mais seguro. As pessoas que trabalham no OWASP não ganham nada além da satisfação de contribuir para a comunidade e aprender muito no processo. Lá você irá encontrar recursos que podem ajudar a:

• Aprender sobre vulnerabilidades, ameaças, ataques e principalmente, como evitar tudo isso no ambiente sob sua responsabilidade.
• Conhecer como funcionam e aprender a evitar as vulnerabilidades mais comuns no mundo web, que são listadas no OWASP Top 10 e foram traduzidas pelo Chapter Brazil para o português.
• Incluir etapas de segurança no processo de desenvolvimento de software, ou mesmo revisar o que já tem pronto para descobrir se melhorias neste escopo são necessárias. O CLASP (Comprehensive, Lightweight Application Security Process), o OWASP Guide 2.0 e o OWASP Web Security Certification Criteria são recursos gratis, de excelente qualidade e que estão disponíveis.

SANS

O SANS Institute é bastante conhecido pelas certificações técnicas que provê, porém nem todos sabem que o site deles é um enorme repositório de conhecimento, onde existe desde material de leitura acadêmia em segurança e guias para a criação de políticas de segurança, até formas de evitar as SANS Top 20. Um dos projetos que eles mantêm que mais gosto, é o Security Consensus Operational Readiness Evaluation (SCORE).

O SCORE tem como objetivo manter no site do SANS uma lista de padrões e checklists voltados para a manutenção de níveis mínimos de segurança. Ainda engatinhando, tem somente um documento disponível e muito mais voltado ao mercado norte-americano, mas estão sendo desenvolvidos documentos para UNIX, handhelds e firewalls. Contribuir para esta iniciativa, é sem dúvida uma excelente forma de aprender e compartilhar o conhecimento com a comunidade.

Concluindo

Impedir a ocorrência de problemas em Segurança da Informação é uma tarefa impossível, que ninguém em sã consciência pode assumir de forma séria, porém, evitar que erros primários gerem vulnerabilidades na infra-estrutura de TI é uma tarefa simples, que exige do corpo técnico somente boa vontade e capacidade mínima para administrar os controles de forma adequada.

Talvez na próxima vez que o seu gerente quiser falar sobre GRC, Identity Management, Risk Management e outros processos avançados em Segurança da Informação, seja bom lembrar que o básico não pode ser esquecido e o corpo técnico tem um papel tão fundamental no suporte ao processo de gestão como os demais. Seguir as recomendações para evitar a ocorrência dos problemas listados no OWASP Top 10 e SANS Top 20 é uma questão de bom senso, e certamente irá evitar muitos problemas que custarão bem mais para serem resolvidos.

Uma versão em PDF deste artigo está disponível para download na página Meus Documentos deste blog.

Uma das coisas que sempre gostei em práticas de linguagem e comunicação foi de expressões em latim que sintetizam situações, algo bastante usado por advogados e juristas. Uma delas é Si vis pacem, para bellum, que literalmente significa Se você quer paz, prepare-se para a guerra. Preparar a sua empresa para uma auditoria de sistemas é exatamente isso, ter muito trabalho para enfrentar uma situação que pode resultar em um grande problema, ou ser uma mera formalidade.

O primeiro artigo desta série mostra os 10 tópicos que são vistos com mais freqüência pelos auditores de sistemas, porque eles podem ser problemas se não tratados adequadamente e como evitar que cada um se transforme em uma encrenca.
Nesta segunda parte, vou abordar de forma simplificada a postura dos auditores e Security Officers no processo, as características mais comuns de uma auditoria de sistemas e que tipo de ações devem ser feitas para simplificar o processo, transformando a atividade em uma formalidade que não deve dar problemas para ninguém, e sim ajudar ambas as partes a criarem um ambiente mais seguro para seus clientes.

Quis Custodiet Ipsos Custodis

A tradução desta expressão é “quem irá vigiar os vigilantes”, e se aplica muito bem ao papel de um auditor de sistemas. Normalmente, ele é contratado para identificar problemas em um ambiente informatizado cuja segurança deve ser administrada por um Security Officer. Ou seja, ele deve ajudar a empresa a manter o nível adequado de segurança fazendo uma análise independente. Quando o processo se mantém a este escopo, a auditoria é uma excelente ferramenta para o CIO, que tem uma visão de onde deve investir em controles adicionais e remover aqueles que não dão o resultado esperado, e também para o Security Officer, que tem na auditoria uma revisão de qualidade do seu trabalho e uma garantia para a organização que ele está sendo vigiado de forma adequada.

O problema é quando a auditoria é transformada em uma ferramenta política, na qual um ponto irrelevante é transformado em um problema. Isto acontece não só porque alguns auditores vêem na obtenção de pontos uma vitória profissional – que inclusive reflete no bônus – mas também porque falta um entendimento inicial de como a segurança é administrada. Então, como sobreviver?

Definir o nível de risco ao qual a empresa está disposta a ser submetida é a primeira etapa. Não basta fazer uma Análise de Risco e ter os resultados em mãos para apresentar, é necessário sentar com as pessoas que pagam a conta e deixar muito claro quais vulnerabilidades existem, que problemas podem advir da exploração das mesmas e qual é a relação entre os custos para resolver e o impacto decorrente.

Quando isto acontece, você pode receber a excelente notícia de que os recursos necessários para corrigir as vulnerabilidades e mantê-las fora do radar serão fornecidos. Ou que a empresa não pode investir nisto no momento, o que é frustrante, mas acontece em boa parte dos lugares.
Nesta segunda opção, você deve documentar de forma clara – ou seja, pegar a assinatura de quem assume o risco – que o problema foi apresentado, aceito e a empresa optou por não agir. Este documento deve ser revisado periodicamente e usado não só como ferramenta de discussão com auditores, mas também como instrumento de análise contínua de risco e busca de investimentos na área.

Um bom auditor vai aceitar o documento e ir direto à área que optou pelo risco, para entender porque isto aconteceu e o quanto problemático para a empresa é ficar com uma vulnerabilidade em aberto. Os frameworks (ex. ISO 27001 e CobiT) )disponíveis no mercado cumprem muito bem esta função, pois permitem o mapeamento do ambiente, a análise e a gestão de riscos, com base em melhores práticas adotadas pelo mercado.

Esse Quam Qui Videre

Não somente parecer, mas realmente ser. A frase usada por alguns autores romanos, em especial Cícero em De amicitia e mostra o espírito de como a segurança deve ser administrada. Manter relatórios e controles que são puro vaporware é uma prática comum em algumas empresas, que vêem nisso uma excelente ferramenta para mostrar que existe um controle eficaz implantado.

Um exemplo recorrente são os logs de servidores. Nos meus tempos de auditor – sim já fui um – cansei de ver quilos de papel onde estavam impressos os logs de um determinado servidor de arquivos e ninguém analisava aquela informação, o que era impossível fazer manualmente. Não tem escapatória. Os controles de segurança e ferramentas de gestão devem ser desenvolvidos de acordo com a realidade de mercado e orçamento disponível de cada empresa, o valor que ela dá para a Segurança da Informação, e principalmente, ter um processo de gestão de condizente com o que os “donos do negócio”  acham importante.

Isso está claramente relacionado ao tópico anterior, e defender um controle vaporware não só deixa qualquer auditor irritado em ver seu tempo desperdiçado, como também mostra uma falta de entendimento da gestão de segurança, e a conseqüente incompetência na função. É impossível controlar tudo. Um bom auditor sabe disso e entenderá perfeitamente se falhas forem encontradas, desde que elas tenham sido previamente identificadas, os problemas endereçados às áreas competentes e constantemente revisados.

A palavra chave neste sentido é o Gerenciamento de Risco, que está relacionado à como os frameworks são administrados dentro da organização. Não confunda o fato de ter um framework implementado, que não necessariamente significa que os riscos são geridos de forma adequada. Se a organização onde você trabalha valoriza muito os quilos de papel, assinaturas em todos os cantos e nunca consegue recursos para administrar isto tudo, mostre o quanto inútil é esta situação. Se os “donos do negócio” persistirem, procure outro lugar, esta posição é nociva para a carreira de qualquer um.

Per ardua ad Astra

Uma frase utilizada pela Royal Air Force britânica, literalmente significa “através das adversidades, em direção às estrelas”. Trazendo para a nossa realidade, não importa o tamanho do problema, ele deve ser resolvido. Mesmo parecendo uma bobagem, é mais do que comum ver empresas onde os problemas de segurança não são resolvidos porque “dão muito trabalho” ou “as pessoas não quiseram fazer”. Se estas frases saem da boca de um Security Officer, ele está na função errada.

Apresentar um problema para um auditor e dizer que ele não foi resolvido porque é complicado, é dar um tiro no pé. Mostra falta de determinação na função de gestão (um problema do Security Officer) ou limitação no entendimento da importância da função (um problema da organização). Insisto em recorrer aos dois tópicos anteriores, para que o trabalho seja feito de forma adequada, é necessário que o Security Officer tenha os poderes adequados à função e saiba fazer bom uso dos mesmos.

Eu já vi em duas ocasiões, um relatório de auditoria apontar que a falta de entendimento da organização sobre o papel do Security Officer era a causa dos problemas. Em uma delas que era do segmento financeiro, o CIO foi trocado.

Semper fidelis

Já li estudos de empresas conceituadas afirmarem que uma auditoria é fundamentalmente um processo de negociação. Se isto for visto como uma explicação detalhada dos processos e controles utilizados, concordo. Se for visto como um jogo de gato e rato onde o auditor acha um ponto e o Security Officer tem que defender a organização contra ele, temos um problema ético nas mãos.

Existe aí um ponto crucial. Se o Security Officer tem em mãos um processo de gestão adequado, onde as vulnerabilidades são tratadas da forma correta, não há negociação, há explicação e entendimento do que é feito. Semper fidelis é um termo usado pelos marines norte-americanos e significa “sempre confiável”.

Para sobreviver a uma auditoria de sistemas é necessário manter um ambiente confiável, ser confiável e usar palavras certas e precisas nas discussões. Isso é simples, mas exige dedicação profissional, preparação acadêmica, atualização constante e apoio da organização. Como em qualquer emprego onde se queira ser bem sucedido.

O maior problema que vejo é a insistência de muitas organizações de tratarem a Segurança da Informação como um item menor, e não como um processo crucial para manter a competitividade – guardadas as proporções de acordo com o segmento onde elas atuam, é claro. É nosso papel como profissionais da área mudar isso. Participar de associações com voz ativa no mercado, insistir com o Governo para que leis relevantes sejam aprovadas, esclarecer aos nossos pares e chefes do que tratamos e desmistificar a função, é o que temos que fazer. Chega de “seu site pode ser invadido” ou “isso pode causar um grande prejuízo que não podemos calcular”.

Sejamos objetivos, precisos, profissionais e bem posicionados. É assim que auditores e Security Officers devem agir, não é mesmo?