Este artigo está também disponível para
leitura on-line no Scribd.
por Eduardo V. C. Neves | OperaçõesNas próximas semanas o PCI Council irá promover uma revisão no PCI Data Security Standard (PCI DSS), buscando esclarecer pontos que causam confusão na implementação do padrão pelas empresas. É uma iniciativa louvável e que mostra o comprometimento deste padrão em buscar o estabelecimento de um nível de segurança adequado nas empresas, porém a interpretação errada pode levar mais uma vez as empresas a uma falsa sensação de segurança ao estarem aderentes ao padrão. Este artigo aborda como o Requerimento 6 pode ser plenamente atendido com o desenvolvimento e a implementação de um Secure Development Lifecycle nas empresas, reduzindo de forma significativa a probabilidade de não-aderência ao padrão e estabelecendo um nível de proteção real e eficiente para as aplicações utilizadas no trato dos dados do portador do cartão.Snake Oil e Aderência a um Padrão
Em 2008 eu publiquei um artigo intitulado “
Entendendo o PCI: Porque os padrões promovidos pelo PCI Council são bem mais que um simples snake oil”. A minha opinião não mudou nem um pouco nestes dois anos, ainda acho que o PCI DSS e os padrões relacionados pode ser uma revolução ao levar a segurança técnica para empresas que nem sabiam o que era antes da obrigação.
Porém, como qualquer padrão, ele está sujeito à forma como as pessoas o interpretam, sejam elas as obrigadas a implementar os controles ou as que o auditam. O ainda impressionante caso da
Heartland Payment Systems deixou claro para os mais céticos que tamanho corporativo e imensos investimentos em segurança não são suficientes para evitar o comprometimento de dados privados. O que tenho escutado de algumas pessoas é uma interpretação equivocada do Requerimento 6, onde a aderência está fundamentada em testar as aplicações desenvolvidas em busca das vulnerabilidades listadas no
OWASP Top 10 e ajustar estas para ter um software seguro.
O OWASP Top 10 é uma lista muito bem construída e constantemente atualizada que apresenta as dez vulnerabilidades mais comuns em aplicações web, o que pode acontecer em sua exploração e como evitar que ocorram. Só isso, e como não é um padrão, acho incoerente afirmar que está “aderente”. Além do mais, esta lista é somente um dos requisitos solicitados pelo PCI DSS, não sendo exaustivo e devendo ser considerado parte do processo, como o próprio texto do padrão informa em “6.3. Desenvolver aplicativos de software de acordo com o PCI DSS (por exemplo, autenticação segura e registros) e com base nas melhores práticas do setor, além de incorporar a segurança das informações em todo o ciclo de vida do desenvolvimento dos softwares. “
Limitar a segurança das aplicações ao que está recomendado no OWASP Top 10 é um
snake oil tremendo que possivelmente irá satisfazer os auditores e deixar a empresa completamente exposta com vulnerabilidades tão sérias quando um
Cross Site Scripting. O OWASP Top 10 lista problemas mais comuns, e não todos os problemas. Falhas de lógica que são exclusivas em aplicações específicas não aparecem por motivos óbvios e podem ser extremamente danosas. Quando existe uma sensação de segurança, as pessoas tendem a naturalmente baixar a guarda por acharem que o problema está resolvido, focando os esforços em outros pontos de atenção. Se isso ocorre com uma “aderência” ao OWASP Top 10, mais um problema é criado.
As alterações propostas pelo PCI Council
O que o PCI Council busca com as alterações propostas, é estabelecer uma abordagem mais compreensiva para as empresas uma vez que as próprias recomendações atuais do Padrão muitas vezes são confusas para profissionais que não trabalham com IT Security, ou até mesmo para pessoas experientes. Em especial, duas alterações afetam diretamente o Requisito 6 e serão alteradas para esclarecer como as empresas devem tratar os seguintes pontos:
- Evoluir o Requerimento 6.2 para que seja possível criar um ranking de vulnerabilidades de acordo com seu risco de exploração, o que possivelmente será concluído com a recomendação de um processo de tratamento a médio prazo.
- Esclarecer o Requerimento 6.5 para eliminar redundâncias no que é solicitado no ponto 6.3.1 e ainda incluir novos padrões de mercado como recomendação, além do OWASP Top 10.
O Requerimento 6.2
Eu insisto na abordagem que estabelecer um nível risco para uma vulnerabilidade é algo extremamente complexo e depende de interações que só podem ser alcançadas em um processo de
Risk Assessment, algo que empresas que querem gastar cada vez menos com o PCI DSS e simplesmente alcançar a certificação, dificilmente irão investir. Porém, ao substituir o termo “risco” por impacto total, derivado do que pode acontecer na exploração de uma vulnerabilidade e a probabilidade de ocorrência, baseada no seu conhecimento e existência de formas de automação, faz sentido sim. Mas ainda com essa consideração, o que fazer no caso de efetivação de uma ameaça de baixo impacto total que possa causar um estrago inesperado?
Para ilustrar este cenário, tomo como exemplo um dos projetos que fizemos para identificar vulnerabilidades em aplicações web. De todas as vulnerabilidades que identificamos, duas eram consideradas de baixo impacto total, mas se ambas fossem exploradas de forma simultânea, o resultado poderia levar a empresa a pagar uma multa considerável para um de seus parceiros comerciais. Esta informação não era de conhecimento do nosso cliente, e foi obtida graças ao fato de um dos membros de nossa equipe ter trabalhado na mesma indústria e passado por um cenário similar no passado. Como fica o ranking de vulnerabilidades neste caso?
Indo um pouco além, existe uma enorme probabilidade das empresas desconsiderarem fatores totalmente relevantes para a forma como uma vulnerabilidade pode ser explorada:
- Falhas na camada de arquitetura que podem ser ignoradas ou mesmo não existir durante a elaboração do ranking, tal como o posicionamento de um banco de dados no lugar errado.
- Problemas na camada de rede de dados que também não são considerados, como falhas na implementação de HTTPS ou falhas correlatas como a persistente inexistência da flag SECURE nos cookies utilizados.
A idéia é muito boa, mas tenho receio de que a prática comum será simplesmente criar um ranking de vulnerabilidades que serão tratadas de forma isolada, o que volta na falsa sensação de segurança que abordei no começo deste artigo.
O Requerimento 6.5
Na versão atual do padrão, os Requisitos 6.3.1 e 6.5 tem textos e objetivos similares, ambos exigem que as aplicações sejam desenvolvidas seguindo critérios mínimos de segurança. Enquanto o 6.3.1 estabelece o processo de desenvolvimento seguro evitando vulnerabilidades conhecidas e indo além ao abordar processos (ex. Separação de funções), o 6.5 indica o OWASP como fonte de recursos através de um nome genérico: “
Open Web Application Security Project Guide”.
Colocar estes conteúdos em um só requerimento é uma excelente idéia, porém eu iria um pouco além para aproveitar a ocasião e esclarecer pontos que são óbvios para quem conhece o processo de desenvolvimento seguro, mas não tem sido seguidos pelas pessoas que respondem pela adequação ao PCI DSS na maioria dos casos que conheço.
- Testar as alterações que ocorrem em uma aplicação, incluindo uso de patches é correto, mas o texto é muito confuso tanto em inglês quando em português: “6.3.1. Teste de todos os patches de segurança e alterações de configuração no sistema e no software antes da implementação”. Esclarecer este ponto é fundamental, uma vez que leva as pessoas a entenderem que o cerne da questão são patches, e não alterações como um todo.
- Deixar claro que o OWASP Top 10 é apenas uma das várias referências e não deve ser um limitador. Quando o texto aborda “... com base nas diretrizes de codificação seguras, como o Guia do projeto de segurança do aplicativo aberto da Web.” abre demais o assunto e confunde qualquer um que não tenha experiência em IT Security. A propósito, o OWASP mantém um número enorme de guias de suporte para desenvolvimento seguro, não seria muito mais assertivo dar o nome do que é recomendado?
Indo além neste requerimento, o que fazer com as aplicações legadas que estão vulneráveis e vão demorar um bom tempo para entrarem no circuito de desenvolvimento seguro, se este efetivamente for criado da forma correta? Sem dúvida existe o Requerimento 6.6 que recomenda o uso de um
Web Application Firewall (WAF), mas um WAF não protege aplicações de falhas de lógica e para ser efetivo depende de uma administração que inclui tunning de suas funções. Novamente, manter requerimentos isolados é um risco que irá gerar uma grande carga de trabalho e investimentos contínuos das empresas sem que exista uma real elevação do nível de segurança das aplicações utilizadas. É necessário pensar de forma integrada.
Uma abordagem mais eficiente
Para obter uma aplicação do PCI DSS sem que este seja mais um
snake oil é necessário olhar o padrão como um todo e estabelecer critérios que façam sentido para a empresa. No caso da manutenção de aplicações seguras, recomendo um abordagem que inclua o uso de três funções conjuntas: a proteção para o legado de aplicações, um ciclo de desenvolvimento seguro e a capacitação adequada das empresas e seus técnicos para garantir a evolução do conhecimento em segurança, e a conseqüente melhoria do nível de segurança.
Tratando o legado de aplicações
Administrar um legado é sempre um desafio para qualquer empresa, são computadores antigos que não suportam atualizações, softwares que não funcionam com os requisitos atuais mas não podem ser trocados por estarem integrados com outros sistemas e aplicações que precisam ser tratadas para adequar a segurança, e isso nem sempre depende somente da empresa. Em comum, existem aspectos operacionais que não estão escritos no PCI DSS e em nenhum outro padrão, mas fazem parte do dia-a-dia da maioria das empresas e devem ser considerados como pontos de criação de um processo que funcione.
- Aplicações legadas em áreas de negócio podem ter sido negociadas diretamente com o fabricante sem o envolvimento de TI. Como resultado, elas ficam “escondidas” no parque de produtos da empresa, e devem ser buscadas uma a uma para adequação.
- Aplicações legadas podem ter funções em sua construção que impeçam alterações para adequação de segurança. Falta de acesso ao código-fonte e necessidade de operação sob um usuário administrator são dois pontos comuns e que necessitam de tratamento especial.
- Aplicações legadas podem suportar processos críticos do negócio, e sua interrupção depende de muito planejamento e negociação com as áreas envolvidas. É impraticável pensar que será possível testar e adequar a segurança dentro de um cronograma feito somente por TI.
- O volume de aplicações legadas, pode levar a uma necessidade de investimento nos testes de segurança que nunca será aprovado pelos responsáveis. Em um de nossos clientes, já trabalhamos com 80 aplicações com estas características que precisavam ser adequadas em 90 dias.
Para adequar a segurança deste legado de forma eficiente é fundamental estabelecer a abordagem de testes mais adequada para o volume e características únicas (ex. Tipo de linguagem utilizada) em cada cenário e desenvolver uma ação onde fique muito claro como o processo será feito e o que é esperado de cada área participante. Estratégias que funcionam e podem ser utilizadas em praticamente qualquer mercado estão baseadas nesta premissa.
Escolhendo o modelo de teste adequado
Existem, no mínimo, três formas de se buscar vulnerabilidades em aplicações: security scan, penetration test e code review. As diferenças entre elas podem ser resumidas no gráfico abaixo, onde o nível de esforço e qualidade dos resultados estão diretamente relacionados.
- Security Scan: Identifica vulnerabilidades comuns (ex. Cross Site Scripting e SQL Injection), porém não cobre falhas de lógica e violações de confiança na aplicação. É uma abordagem onde deve-se esperar somente uma visão geral das vulnerabilidades.
- Penetration Test: Feito da forma correta, envolve o security scan e uma série de testes manuais para validação de resultados obtidos por ferramentas e identificação de vulnerabilidades lógicas na interação entre os componentes (ex. Servidores Web).
- Code Review: Como envolve a análise do código e a forma como a aplicação se comporta em modo de execução, é um teste completo que permite identificar vulnerabilidades e ainda modelar as ameaças relacionadas.
Usar somente uma destas abordagens para testar o nível de segurança de aplicações é uma opção que não recomendo, se você quiser preservar o seu investimento e ter uma administração de segurança que consiga equilibrar os recursos disponíveis com a obtenção de um nível de proteção adequado. Desenhar uma abordagem que obtenha o melhor de cada modelo de teste é fundamental para garantir uma velocidade aceitável na obtenção de resultados e criar um ranking de quais aplicações devem ser adequadas no começo da fila de forma correta.
Uma das formas que usamos com sucesso nos últimos anos é simples e funciona muito bem:
- As aplicações são todas submetidas a um security scan, onde os resultados mostram quais estão com a maior quantidade de vulnerabilidades simples. Este resultado é discutido com o cliente para que ele defina - com o nosso apoio - onde iremos aprofundar os testes.
- Penetration Tests e Code Review são utilizados em conjunto, de acordo com as características da aplicação, como nos casos não é possível obter acesso ao código fonte ou não existe tempo hábil para testes mais profundos.
Com os resultados em mãos, é possível apresentar três resultados que permitem adequar o nível de segurança imediatamente e em ações futuras, onde os erros são eliminados e a camada de proteção das aplicações adequada.
- Vulnerabilidades de simples resolução - em boa parte dos casos - podem ser imediatamente resolvidas e muitas vezes a aplicação da recomendação de melhoria elimina uma grande quantidade de pontos identificados, como gerar processos de validação de dados que eliminam um Cross Site Scripting.
- Aplicações desenvolvidas internamente quase sempre apresentam erros similares que denotam o tipo de capacitação necessária para o time de desenvolvimento. Com este dado em mãos, é previsto um treinamento adequado que, aos poucos, permite a criação de aplicações mais seguras.
- Aplicações adquiridas externamente - onde o código fonte quase nunca está disponível - tem suas falhas identificadas, e este resultado pode ser utilizado como massa de manobra para negociação com os fornecedores através de cláusulas contratuais e adoção de responsabilidade compartilhada.
Este primeiro passo trata do legado de aplicações e estabelece um nível mínimo de segurança que permite basear a adoção de um processo de desenvolvimento seguro na empresa. Porém, existe um ponto que é comum a maioria dos negócios e que já foi citado neste artigo: o que fazer com as aplicações suja correção não pode ser feita até um determinado momento temporal?
A proteção das aplicações de missão crítica
Missão crítica é um termo que pode ser aplicado de diversas formas e acaba muitas vezes caindo no jargão de frases de efeito. Neste caso, vamos considerar que as aplicações de missão crítica são as que não podem ser interrompidas até um determinado momento, independente se o motivo é o suporte direto a um processo de negócio (ex. Um carrinho de compras para um e-commerce) ou uma impossibilidade operacional (ex. Dependência de um componente compartilhado com outros produtos).
A questão é que a aplicação não pode ser interrompida para que as vulnerabilidades identificadas sejam tratadas, e é necessário impedir que ela seja atacada. Neste ponto é onde identificamos a função de um
Web Application Firewall (WAF) que irá permitir o funcionamento do componente sem que ataques a estas falhas sejam efetivados. Note que para um WAF resultar em uma proteção eficiente, não basta colocar uma caixa no data center e esperar que ele aja sozinho, é necessário um mínimo de interação com o produto e a administração de pelo menos duas funções:
- O tunning inicial do produto depende do comportamento das aplicações que estão sendo protegidas. O conjunto de regras que vem de fábrica com o WAF tem que ser entendido e utilizado para cada componente sob sua guarda, uma vez que elas são padronizadas exatamente por estarem sob esta premissa.
- O virtual patching, que nada mais é do que criar ou adequar uma regra no WAF para proteger a aplicação de uma ou mais falhas, deve ser criado de acordo com cada situação. Claro que para uma grande maioria dos casos, o uso de um template fornecido no produto basta, porém são as exceções que devem ser olhadas mais de perto.
E ainda que já tenha sido citado, lembre-se que um WAF tem funções de proteção específicas e nunca deve ser considerado um substituto para testes de segurança e os processos de correção resultantes. O WAF é um guardião que provê um bom nível de proteção para as suas aplicações enquanto elas são adequadas em novos releases.
A adequação através de um SDL
A adoção de um
Secure Development Lifecycle (SDL) é a base da proposta de abordagem mais eficiente descrita neste artigo, e é neste momento em que ele tem o seu papel definido. Existem diversas metodologias disponíveis na Internet e muito bem estruturadas, em comum elas apresentam ciclos que devem ser adotados de acordo com o tamanho da empresa, quantidade de esforço alocado e capacitação da equipe responsável.
Uma vez estabelecido, o SDL deve ser utilizado para adequar o nível de segurança das aplicações componentes do legado que foram testadas, evitar a ocorrência de novas vulnerabilidades pela inserção dos controles que permeiam o processo e ainda para uma função que fecha a proposta de abordagem apresentada.
Capacitação contínua e abrangente
As características do processo de desenvolvimento que geram vulnerabilidades nas aplicações, dependem muito do nível de capacitação da equipe técnica não só em como um SDL funciona, mas ainda em competências específicas de desenvolvimento seguro. Existem abordagens gerais, que permitem eliminar boa parte das falhas oriundas da falta de tratamento de dados, ainda abordagens específicas que tratam da forma como os códigos são escritos.
Porém, de nada adianta se o treinamento não for direcionado e abrangente. O direcionamento, se dá através da identificação das causas que geraram as vulnerabilidades - um dos resultados colaterais dos testes realizados - e adequação do treinamento para garantir a capacitação da equipe em competências que estejam direcionadas ao que eles fazem, ao invés de um tratamento geral que muitas vezes tem uma carga horária excessiva para a realidade destes profissionais e não chega nos pontos fundamentais para a empresa.
A abrangência se dá pela introdução do processo em todas as áreas da empresa envolvidas e pela administração de políticas que garantam a autoridade do SDL. Um lugar comum que deve ser evitado ao máximo é uma área de negócios exigir a publicação de uma determinada aplicação sem que ela passe pelo tratamento adequado, invocando o “engessamento do processo” e o “impacto nos negócios causado por TI” como causas.
É óbvio que nesta situação, a causa é da falta de planejamento da área de negócios, que não soube adequar a sua forma de trabalho com as regras da empresa. Porém, para que isso não se torne uma exceção que vire regra e realmente funcione, as pessoas destas áreas tem que ser capacitadas em como as regras funcionam. Esperar que o processo seja criado e todos o conheçam é inocente demais, mas é uma das formas como vejo as coisas acontecerem em muitos lugares.
Conclusão
Uma justificativa financeira
O PCI DSS é um padrão que exige o desenvolvimento e manutenção de segurança nas aplicações, e as multas e conseqüências do seu não cumprimento certamente são os principais motivadores para a aderências das empresas. Porém, limitar o escopo ao fluxo dos dados do portador do cartão pode ser um erro com conseqüências que vão muito além de uma multa imposta por uma bandeira de cartão de crédito.
Valores que definem as perdas relacionadas a ataques bem sucedidos contra componentes informatizados utilizados por empresas e pessoas são apresentados em pesquisas que existem há mais de duas décadas e não só serviram para as empresas definirem suas estratégias de proteção, como ainda basearam a criação de outros controles de mercado como a Seção 404 da
SOX e o
HIPAA. Porém, quando as falhas atingem aplicações corporativas - com suas versões web inclusas - o cenário deve ser considerado de forma específica.
- Uma pesquisa conduzida pelo Ponemon Institute apontou que, apesar da maior preocupação ser o furto de dados corporativos através de falhas em aplicações web, 70% dos entrevistados afirmaram que suas empresas não alocam recursos suficientes para proteger estes componentes, e que 34% das vulnerabilidades críticas não são corrigidas.
- O Gartner Group afirma que 75% das falhas de segurança exploradas com sucesso estão em aplicações e o National Institute of Standards and Technology (NIST) estima este percentual em 92%, tomando como base os resultados de órgãos do Governo dos E.U.A.
No Brasil não existem ainda pesquisas sobre o tema com amplitude suficiente para especificar o cenário em todo o mercado. Porém, desenvolvemos uma quantidade considerável de projetos nesta área desde 2008 em empresas de grande e médio porte e os resultados não diferem da realidade apresentada nas pesquisas citadas.
Se tomarmos como base para uma projeção racional na realidade do nosso País, a estimativa de movimentação superior a
R$ 14 bilhões no comércio eletrônico para 2010, mostra o valor dos prejuízos que as empresas podem sofrer com ataques bem sucedidos às aplicações web que suportam este tipo de processo de venda. Porém, existem custos ocultos que nem sempre são percebidos quando existe uma análise de falhas em aplicações.
- Aplicações que permitam aos clientes de uma empresa serem lesados pela exploração de uma falha podem gerar processos legais com base no Código Civil, sendo que já existe jurisprudência sobre o assunto.
- Falhas em aplicações que permitam a inserção de malware e posterior contaminação de usuários, além de poderem ser utilizados para processos dos lesados, geram um grande impacto negativo na mídia como ocorrido em 2009 com uma série de web sites brasileiros.
Considere que, além do crescimento anual de 35% no acesso da população à Internet, as redes sociais hoje movimentam 62% do tráfego da Internet brasileira e a exposição de uma vulnerabilidade nestes canais, assim como a opinião do público-alvo de qualquer empresa, estão totalmente capilarizadas e com
alta velocidade de proliferação. Pense além do PCI DSS, limitar o escopo e buscar o máximo de controles com o mínimo de investimentos em uma porção do seu Ambiente Informatizado é arriscado e não permite o uso de uma grande oportunidade para estabelecer um processo de segurança que atenda a todas as aplicações, resultando em aspectos financeiros positivos para toda a empresa.
Metodologia é somente a base para um processo operacional
Implementar controles de segurança adequados no processo de desenvolvimento de software, proporciona a garantia de que as funções esperadas para os produtos serão atendidas com a redução dos riscos na exploração de vulnerabilidades para níveis realmente aceitáveis. Porém implementar estas medidas pode ser um processo impossível de ser concluído, caso a abordagem não seja estabelecida para atender à realidade da empresa e aceitar a evolução natural do nível de maturidade estabelecido.
As metodologias citadas neste artigo como base para um SDL são similares ao proporem um processo estruturado de inserir práticas de segurança no processo de desenvolvimento de software. Excelentes em suas propostas, porém freqüentemente implementadas de forma equivocada no Brasil e injustamente definidas como panacéias por não atenderem a premissas que quase nunca foram bem estabelecidas.
O problema é que elas mostram como implementar as práticas de segurança em um nível de maturidade crescente, mas não como enfrentar características comuns das empresas brasileiras tais como o desconhecimento técnico da equipe em práticas de segurança, a necessidade de usar a mesma mão-de-obra para práticas diferentes (e muitas vezes antagônicas, como segurança e performance), e a prática comum de colocar em produção aplicações que atendam objetivos de negócio imediatos, ainda que sejam vulneráveis.
Use as metodologias como base, pense em como a sua empresa funciona e equilibre estes aspectos. O PCI DSS tem sido um problema em muitas implementações pela inexistência de uma análise criteriosa de como criar controles amplos e que não só atendam os requerimentos, como ainda ampliem o nível de segurança como um todo. Apesar de parecer um aumento desnecessário de investimento, esta opção permite que a empresa realmente atinja um bom nível de segurança, aderindo ao PCI DSS como conseqüência das práticas que permitem a gestão em Segurança da Informação.
Não deixe o PCI DSS ser um
snake oil na sua empresa, depende somente de como ele será interpretado e de conseguir usar as limitações deste padrão a seu favor. O Requerimento 6 pode ser a oportunidade ideal para que finalmente um SDL seja implementado, e todas as aplicações tenham as proteções adequadas, beneficiando não só a aderência ao padrão, mas a forma como os seus clientes fazem negócios com você. Eles irão perceber a diferença, é só uma questão de mais algum tempo.
Sobre o Autor
Eduardo Vianna de Camargo Neves trabalha com Segurança da Informação desde 1997, tendo atuado como auditor, consultor e Security Officer. É sócio-fundador e Gerente de Operações da Conviso IT Security, responsável pela administração e estratégia da empresa. Serve ainda como membro do Capítulo Brasil do OWASP, do OWASP Global Education Committee na América Latina e voluntário no (ISC)2.
