Você está na página 1de 6

Porque o Requisito 6 Nas próximas semanas o PCI Council1 irá promover uma revisão no PCI Data Security Standard

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
do PCI DSS pode ser 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
mais um Snake Oil padrão.

Eduardo V. C. Neves Este artigo aborda como o Requerimento 6 pode ser plenamente atendido com o desenvolvimento
Departamento de Operações 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 oil2”. 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 Systems3 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 104 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 oil5
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
BRASÍLIA | SÃO PAULO | CURITIBA que são exclusivas em aplicações específicas não aparecem por motivos óbvios e podem
Rua Marechal Hermes 678 CJ 32 ser extremamente danosas.

CEP 80530-230, Curitiba, PR Quando existe uma sensação de segurança, as pessoas tendem a naturalmente baixar a
T (41) 3095.5736 guarda por acharem que o problema está resolvido, focando os esforços em outros pontos
T (41) 3095.3986 de atenção. Se isso ocorre com uma “aderência” ao OWASP Top 10, mais um problema é
criado.
www.conviso.com.br

Conviso IT Security | White Papers | Porque o Requisito 6 do PCI DSS pode ser mais um Snake Oil 1
Conviso IT Security | White Papers

As alterações propostas pelo PCI Council correlatas como a persistente inexistência da flag SECURE nos
cookies utilizados.
O que o PCI Council busca com as alterações propostas, é estabelecer
uma abordagem mais compreensiva para as empresas uma vez que A idéia é muito boa, mas tenho receio de que a prática comum será
as próprias recomendações atuais do Padrão muitas vezes são simplesmente criar um ranking de vulnerabilidades que serão
confusas para profissionais que não trabalham com IT Security, ou tratadas de forma isolada, o que volta na falsa sensação de segurança
até mesmo para pessoas experientes. Em especial, duas alterações que abordei no começo deste artigo.
afetam diretamente o Requisito 6 e serão alteradas para esclarecer
como as empresas devem tratar os seguintes pontos: O Requerimento 6.5
Na versão atual do padrão, os Requisitos 6.3.1 e 6.5 tem textos e
Evoluir o Requerimento 6.2 para que seja possível criar um
objetivos similares, ambos exigem que as aplicações sejam
ranking de vulnerabilidades de acordo com seu risco de
desenvolvidas seguindo critérios mínimos de segurança. Enquanto o
exploração, o que possivelmente será concluído com a
6.3.1 estabelece o processo de desenvolvimento seguro evitando
recomendação de um processo de tratamento a médio prazo.
vulnerabilidades conhecidas e indo além ao abordar processos (ex.
Esclarecer o Requerimento 6.5 para eliminar redundâncias no Separação de funções), o 6.5 indica o OWASP como fonte de recursos
que é solicitado no ponto 6.3.1 e ainda incluir novos padrões de através de um nome genérico: “Open Web Application Security Project
mercado como recomendação, além do OWASP Top 10. Guide”.

Colocar estes conteúdos em um só requerimento é uma excelente


O Requerimento 6.2
idéia, porém eu iria um pouco além para aproveitar a ocasião e
Eu insisto na abordagem que estabelecer um nível risco para uma
esclarecer pontos que são óbvios para quem conhece o processo de
vulnerabilidade é algo extremamente complexo e depende de
desenvolvimento seguro, mas não tem sido seguidos pelas pessoas
interações que só podem ser alcançadas em um processo de Risk
que respondem pela adequação ao PCI DSS na maioria dos casos que
Assessment, algo que empresas que querem gastar cada vez menos
conheço.
com o PCI DSS e simplesmente alcançar a certificação, dificilmente
irão investir. Testar as alterações que ocorrem em uma aplicação, incluindo
uso de patches é correto, mas o texto é muito confuso tanto em
Porém, ao substituir o termo “risco” por impacto total, derivado do
inglês quando em português: “6.3.1. Teste de todos os patches de
que pode acontecer na exploração de uma vulnerabilidade e a
segurança e alterações de configuração no sistema e no software
probabilidade de ocorrência, baseada no seu conhecimento e
antes da implementação”. Esclarecer este ponto é fundamental,
existência de formas de automação, faz sentido sim. Mas ainda com
uma vez que leva as pessoas a entenderem que o cerne da
essa consideração, o que fazer no caso de efetivação de uma ameaça
questão são patches, e não alterações como um todo.
de baixo impacto total que possa causar um estrago inesperado?
Deixar claro que o OWASP Top 10 é apenas uma das várias
Para ilustrar este cenário, tomo como exemplo um dos projetos que
referências e não deve ser um limitador. Quando o texto aborda
fizemos para identificar vulnerabilidades em aplicações web. De
“… com base nas diretrizes de codificação seguras, como o Guia
todas as vulnerabilidades que identificamos, duas eram consideradas
do projeto de segurança do aplicativo aberto da Web.” abre
de baixo impacto total, mas se ambas fossem exploradas de forma
demais o assunto e confunde qualquer um que não tenha
simultânea, o resultado poderia levar a empresa a pagar uma multa
experiência em IT Security. A propósito, o OWASP mantém um
considerável para um de seus parceiros comerciais.
número enorme de guias de suporte para desenvolvimento
Esta informação não era de conhecimento do nosso cliente, e foi seguro, não seria muito mais assertivo dar o nome do que é
obtida graças ao fato de um dos membros de nossa equipe ter recomendado?
trabalhado na mesma indústria e passado por um cenário similar no Indo além neste requerimento, o que fazer com as aplicações legadas
passado. Como fica o ranking de vulnerabilidades neste caso? Indo
que estão vulneráveis e vão demorar um bom tempo para entrarem
um pouco além, existe uma enorme probabilidade das empresas
no circuito de desenvolvimento seguro, se este efetivamente for
desconsiderarem fatores totalmente relevantes para a forma como
criado da forma correta? Sem dúvida existe o Requerimento 6.6 que
uma vulnerabilidade pode ser explorada: 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
Falhas na camada de arquitetura que podem ser ignoradas ou
mesmo não existir durante a elaboração do ranking, tal como o depende de uma administração que inclui tunning de suas funções.
posicionamento de um banco de dados no lugar errado.
Novamente, manter requerimentos isolados é um risco que irá gerar
Problemas na camada de rede de dados que também não são uma grande carga de trabalho e investimentos contínuos das
considerados, como falhas na implementação de HTTPS ou falhas empresas sem que exista uma real elevação do nível de segurança
das aplicações utilizadas. É necessário pensar de forma integrada.

Conviso IT Security | White Papers | Porque o Requisito 6 do PCI DSS pode ser mais um Snake Oil 2
Conviso IT Security | White Papers

Uma abordagem mais eficiente Escolhendo o modelo de teste adequado


Existem, no mínimo, três formas de se buscar vulnerabilidades em
Para obter uma aplicação do PCI DSS sem que este seja mais um
aplicações: security scan, penetration test e code review. As diferenças
snake oil é necessário olhar o padrão como um todo e estabelecer
entre elas podem ser resumidas no gráfico abaixo, onde o nível de
critérios que façam sentido para a empresa. No caso da manutenção
esforço e qualidade dos resultados estão diretamente relacionados.
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, Security Scan: Identifica vulnerabilidades comuns (ex. Cross Site
um ciclo de desenvolvimento seguro e a capacitação adequada das Scripting e SQL Injection), porém não cobre falhas de lógica e
empresas e seus técnicos para garantir a evolução do conhecimento violações de confiança na aplicação. É uma abordagem onde
em segurança, e a conseqüente melhoria do nível de segurança. deve-se esperar somente uma visão geral das vulnerabilidades.

Tratando o legado de aplicações Penetration Test: Feito da forma correta, envolve o security scan e
Administrar um legado é sempre um desafio para qualquer empresa, uma série de testes manuais para validação de resultados obtidos
são computadores antigos que não suportam atualizações, softwares por ferramentas e identificação de vulnerabilidades lógicas na
que não funcionam com os requisitos atuais mas não podem ser interação entre os componentes (ex. Servidores Web).
trocados por estarem integrados com outros sistemas e aplicações
Code Review: Como envolve a análise do código e a forma como
que precisam ser tratadas para adequar a segurança, e isso nem
a aplicação se comporta em modo de execução, é um teste
sempre depende somente da empresa.
completo que permite identificar vulnerabilidades e ainda
Em comum, existem aspectos operacionais que não estão escritos no modelar as ameaças relacionadas.
PCI DSS e em nenhum outro padrão, mas fazem parte do dia-a-dia da
Comparativo de Resultados em Modelos de Testes de Segurança
maioria das empresas e devem ser considerados como pontos de
1000
criação de um processo que funcione.

Aplicações legadas em áreas de negócio podem ter sido 750


negociadas diretamente com o fabricante sem o envolvimento
de TI. Como resultado, elas ficam “escondidas” no parque de 500
produtos da empresa, e devem ser buscadas uma a uma para
adequação. 250

Aplicações legadas podem ter funções em sua construção que 0


impeçam alterações para adequação de segurança. Falta de Scan Pen Test Code Review
acesso ao código-fonte e necessidade de operação sob um
usuário administrator são dois pontos comuns e que necessitam Usar somente uma destas abordagens para testar o nível de
de tratamento especial. 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
Aplicações legadas podem suportar processos críticos do segurança que consiga equilibrar os recursos disponíveis com a
negócio, e sua interrupção depende de muito planejamento e obtenção de um nível de proteção adequado.
negociação com as áreas envolvidas. É impraticável pensar que
será possível testar e adequar a segurança dentro de um Desenhar uma abordagem que obtenha o melhor de cada modelo
cronograma feito somente por TI. de teste é fundamental para garantir uma velocidade aceitável na
obtenção de resultados e criar um ranking de quais aplicações
O volume de aplicações legadas, pode levar a uma necessidade devem ser adequadas no começo da fila de forma correta. Uma das
de investimento nos testes de segurança que nunca será formas que usamos com sucesso nos últimos anos é simples e
aprovado pelos responsáveis. Em um de nossos clientes, já funciona muito bem:
trabalhamos com 80 aplicações com estas características que
precisavam ser adequadas em 90 dias. As aplicações são todas submetidas a um security scan, onde os
resultados mostram quais estão com a maior quantidade de
Para adequar a segurança deste legado de forma eficiente é vulnerabilidades simples. Este resultado é discutido com o cliente
fundamental estabelecer a abordagem de testes mais adequada para para que ele defina - com o nosso apoio - onde iremos
o volume e características únicas (ex. Tipo de linguagem utilizada) aprofundar os testes.
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 Penetration Tests e Code Review são utilizados em conjunto, de
participante. Estratégias que funcionam e podem ser utilizadas em acordo com as características da aplicação, como nos casos não é
praticamente qualquer mercado estão baseadas nesta premissa. possível obter acesso ao código fonte ou não existe tempo hábil
para testes mais profundos.

Conviso IT Security | White Papers | Porque o Requisito 6 do PCI DSS pode ser mais um Snake Oil 3
Conviso IT Security | White Papers

Com os resultados em mãos, é possível apresentar três resultados O virtual patching, que nada mais é do que criar ou adequar uma
que permitem adequar o nível de segurança imediatamente e em regra no WAF para proteger a aplicação de uma ou mais falhas,
ações futuras, onde os erros são eliminados e a camada de proteção deve ser criado de acordo com cada situação. Claro que para uma
das aplicações adequada. grande maioria dos casos, o uso de um template fornecido no
produto basta, porém são as exceções que devem ser olhadas
Vulnerabilidades de simples resolução - em boa parte dos casos - mais de perto.
podem ser imediatamente resolvidas e muitas vezes a aplicação
da recomendação de melhoria elimina uma grande quantidade E ainda que já tenha sido citado, lembre-se que um WAF tem funções
de pontos identificados, como gerar processos de validação de de proteção específicas e nunca deve ser considerado um substituto
dados que eliminam um Cross Site Scripting. 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
Aplicações desenvolvidas internamente quase sempre suas aplicações enquanto elas são adequadas em novos releases.
apresentam erros similares que denotam o tipo de capacitação
necessária para o time de desenvolvimento. Com este dado em A adequação através de um SDL
mãos, é previsto um treinamento adequado que, aos poucos, A adoção de um Secure Development Lifecycle (SDL) é a base da
permite a criação de aplicações mais seguras. proposta de abordagem mais eficiente descrita neste artigo, e é
Aplicações adquiridas externamente - onde o código fonte quase neste momento em que ele tem o seu papel definido. Existem
nunca está disponível - tem suas falhas identificadas, e este diversas metodologias disponíveis na Internet7 e muito bem
estruturadas, em comum elas apresentam ciclos que devem ser
resultado pode ser utilizado como massa de manobra para
negociação com os fornecedores através de cláusulas contratuais adotados de acordo com o tamanho da empresa, quantidade de
e adoção de responsabilidade compartilhada6. esforço alocado e capacitação da equipe responsável.

Este primeiro passo trata do legado de aplicações e estabelece um Uma vez estabelecido, o SDL deve ser utilizado para adequar o nível
nível mínimo de segurança que permite basear a adoção de um de segurança das aplicações componentes do legado que foram
processo de desenvolvimento seguro na empresa. Porém, existe um testadas, evitar a ocorrência de novas vulnerabilidades pela inserção
ponto que é comum a maioria dos negócios e que já foi citado neste dos controles que permeiam o processo e ainda para uma função
artigo: o que fazer com as aplicações suja correção não pode ser feita que fecha a proposta de abordagem apresentada.
até um determinado momento temporal?
Capacitação contínua e abrangente
A proteção das aplicações de missão crítica As características do processo de desenvolvimento que geram
Missão crítica é um termo que pode ser aplicado de diversas formas e vulnerabilidades nas aplicações, dependem muito do nível de
acaba muitas vezes caindo no jargão de frases de efeito. Neste caso, capacitação da equipe técnica não só em como um SDL funciona,
vamos considerar que as aplicações de missão crítica são as que não mas ainda em competências específicas de desenvolvimento seguro.
podem ser interrompidas até um determinado momento, Existem abordagens gerais, que permitem eliminar boa parte das
independente se o motivo é o suporte direto a um processo de falhas oriundas da falta de tratamento de dados, ainda abordagens
negócio (ex. Um carrinho de compras para um e-commerce) ou uma específicas que tratam da forma como os códigos são escritos8.
impossibilidade operacional (ex. Dependência de um componente
Porém, de nada adianta se o treinamento não for direcionado e
compartilhado com outros produtos).
abrangente. O direcionamento, se dá através da identificação das
A questão é que a aplicação não pode ser interrompida para que as causas que geraram as vulnerabilidades - um dos resultados
vulnerabilidades identificadas sejam tratadas, e é necessário impedir colaterais dos testes realizados - e adequação do treinamento para
que ela seja atacada. Neste ponto é onde identificamos a função de garantir a capacitação da equipe em competências que estejam
um Web Application Firewall (WAF) que irá permitir o funcionamento direcionadas ao que eles fazem, ao invés de um tratamento geral que
do componente sem que ataques a estas falhas sejam efetivados. muitas vezes tem uma carga horária excessiva para a realidade
Note que para um WAF resultar em uma proteção eficiente, não destes profissionais e não chega nos pontos fundamentais para a
basta colocar uma caixa no data center e esperar que ele aja sozinho, empresa.
é necessário um mínimo de interação com o produto e a
A abrangência se dá pela introdução do processo em todas as áreas
administração de pelo menos duas funções:
da empresa envolvidas e pela administração de políticas que
O tunning inicial do produto depende do comportamento das garantam a autoridade do SDL. Um lugar comum que deve ser
aplicações que estão sendo protegidas. O conjunto de regras que evitado ao máximo é uma área de negócios exigir a publicação de
vem de fábrica com o WAF tem que ser entendido e utilizado uma determinada aplicação sem que ela passe pelo tratamento
para cada componente sob sua guarda, uma vez que elas são adequado, invocando o “engessamento do processo” e o “impacto
padronizadas exatamente por estarem sob esta premissa. nos negócios causado por TI” como causas.

Conviso IT Security | White Papers | Porque o Requisito 6 do PCI DSS pode ser mais um Snake Oil 4
Conviso IT Security | White Papers

É óbvio que nesta situação, a causa é da falta de planejamento da custos ocultos que nem sempre são percebidos quando existe uma
área de negócios, que não soube adequar a sua forma de trabalho análise de falhas em aplicações.
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 Aplicações que permitam aos clientes de uma empresa serem
tem que ser capacitadas em como as regras funcionam. Esperar que lesados pela exploração de uma falha podem gerar processos
o processo seja criado e todos o conheçam é inocente demais, mas é legais com base no Código Civil, sendo que existe ampla
uma das formas como vejo as coisas acontecerem em muitos lugares. jurisprudência sobre o assunto13.

Falhas em aplicações que permitam a inserção de malware e


Conclusão posterior contaminação de usuários, além de poderem ser
utilizados para processos dos lesados, geram um grande impacto
Uma justificativa financeira negativo na mídia como ocorrido em 2009 com uma série de
O PCI DSS é um padrão que exige o desenvolvimento e manutenção web sites brasileiros.
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 Considere que, além do crescimento anual de 35% no acesso da
aderências das empresas. Porém, limitar o escopo ao fluxo dos dados população à Internet, as redes sociais hoje movimentam 62% do
do portador do cartão pode ser um erro com conseqüências que vão tráfego da Internet brasileira e a exposição de uma vulnerabilidade
muito além de uma multa imposta por uma bandeira de cartão de nestes canais, assim como a opinião do público-alvo de qualquer
crédito. empresa, estão totalmente capilarizadas e com alta velocidade de
proliferação14.
Valores que definem as perdas relacionadas a ataques bem
sucedidos contra componentes informatizados utilizados por Pense além do PCI DSS, limitar o escopo e buscar o máximo de
empresas e pessoas são apresentados em pesquisas que existem há controles com o mínimo de investimentos em uma porção do seu
mais de duas décadas e não só serviram para as empresas definirem Ambiente Informatizado é arriscado e não permite o uso de uma
suas estratégias de proteção, como ainda basearam a criação de grande oportunidade para estabelecer um processo de segurança
outros controles de mercado como a Seção 404 da SOX8 e o HIPAA9. que atenda a todas as aplicações, resultando em aspectos financeiros
Porém, quando as falhas atingem aplicações corporativas - com suas positivos para toda a empresa.
versões web inclusas - o cenário deve ser considerado de forma
específica. Metodologia é somente a base para um processo operacional
Implementar controles de segurança adequados no processo de
Uma pesquisa conduzida pelo Ponemon Institute10 apontou que, desenvolvimento de software, proporciona a garantia de que as
apesar da maior preocupação ser o furto de dados corporativos funções esperadas para os produtos serão atendidas com a redução
através de falhas em aplicações web, 70% dos entrevistados dos riscos na exploração de vulnerabilidades para níveis realmente
afirmaram que suas empresas não alocam recursos suficientes aceitáveis. Porém implementar estas medidas pode ser um processo
para proteger estes componentes, e que 34% das impossível de ser concluído, caso a abordagem não seja estabelecida
vulnerabilidades críticas não são corrigidas. para atender à realidade da empresa e aceitar a evolução natural do
nível de maturidade estabelecido.
O Gartner Group afirma que 75% das falhas de segurança
exploradas com sucesso estão em aplicações e o National As metodologias citadas neste artigo como base para um SDL são
Institute of Standards and Technology (NIST) estima este similares ao proporem um processo estruturado de inserir práticas de
percentual em 92%, tomando como base os resultados de órgãos segurança no processo de desenvolvimento de software. Excelentes
do Governo dos E.U.A11. em suas propostas, porém freqüentemente implementadas de forma
equivocada no Brasil e injustamente definidas como panacéias por
No Brasil não existem ainda pesquisas sobre o tema com amplitude
não atenderem a premissas que quase nunca foram bem
suficiente para especificar o cenário em todo o mercado. Porém,
estabelecidas.
desenvolvemos uma quantidade considerável de projetos nesta área
desde 2008 em empresas de grande e médio porte e os resultados O problema é que elas mostram como implementar as práticas de
não diferem da realidade apresentada nas pesquisas citadas. segurança em um nível de maturidade crescente, mas não como
enfrentar características comuns das empresas brasileiras tais como o
Se tomarmos como base para uma projeção racional na realidade do
desconhecimento técnico da equipe em práticas de segurança, a
nosso País, a estimativa de movimentação superior a R$ 14 bilhões
necessidade de usar a mesma mão-de-obra para práticas diferentes
no comércio eletrônico para 201012, mostra o valor dos prejuízos que
(e muitas vezes antagônicas, como segurança e performance), e a
as empresas podem sofrer com ataques bem sucedidos às aplicações
prática comum de colocar em produção aplicações que atendam
web que suportam este tipo de processo de venda. Porém, existem
objetivos de negócio imediatos, ainda que sejam vulneráveis.

Conviso IT Security | White Papers | Porque o Requisito 6 do PCI DSS pode ser mais um Snake Oil 5
Conviso IT Security | White Papers

Use as metodologias como base, pense em como a sua empresa 9. Health Insurance Portability and Accountability Act na Wikipedia
funciona e equilibre estes aspectos. O PCI DSS tem sido um problema em http://en.wikipedia.org/wiki/
em muitas implementações pela inexistência de uma análise Health_Insurance_Portability_and_Accountability_Act.
criteriosa de como criar controles amplos e que não só atendam os 10. State of Web Application Security: Pesquisa publicada em 26 de
requerimentos, como ainda ampliem o nível de segurança como um abril de 2010 pelo Ponemon Institute com patrocínio da
todo. Apesar de parecer um aumento desnecessário de investimento, Imperva e WhiteHat Security. Disponível após registro em http://
esta opção permite que a empresa realmente atinja um bom nível de www.imperva.com.
segurança, aderindo ao PCI DSS como conseqüência das práticas que
11. A CISO’s Guide to Application Security: Documento preparado
permitem a gestão em Segurança da Informação.
pelo CIO Custom Solutions Group para a Fortity e disponível
Não deixe o PCI DSS ser um snake oil na sua empresa, depende após registro em http://www.fortify.com.
somente de como ele será interpretado e de conseguir usar as 12. Comércio eletrônico cresceu 40% no Brasil, diz consultoria em
limitações deste padrão a seu favor. O Requerimento 6 pode ser a http://oglobo.globo.com/tecnologia/mat/2010/08/10/comercio-
oportunidade ideal para que finalmente um SDL seja implementado, eletronico-cresceu-40-no-brasil-diz-consultoria-917363680.asp.
e todas as aplicações tenham as proteções adequadas, beneficiando 13. Como o processo 2.0000.00.433758-0/000(1) disponível em
não só a aderência ao padrão, mas a forma como os seus clientes http://www.tjmg.jus.br/juridico/jt_/inteiro_teor.jsp?
fazem negócios com você. Eles irão perceber a diferença, é só uma tipoTribunal=2&comrCodigo=0&ano=0&txt_processo=433758&
questão de mais algum tempo. complemento=0&sequencial=0&palavrasConsulta=responsabili
dade
Sobre o Autor %2520provedor&todas=&expressao=&qualquer=&sem=&radica
Eduardo Vianna de Camargo Neves trabalha com Segurança da l=,
Informação desde 1997, tendo atuado como auditor, consultor e 14. Pesquisa aponta crescimento do acesso à Internet nos lares
Security Officer. É sócio-fundador e Gerente de Operações da Conviso IT brasileiros, em http://www.governoeletronico.gov.br/noticias-e-
Security, responsável pela administração e estratégia da empresa. Serve eventos/noticias/pesquisa-aponta-crescimento-do-acesso-a-
ainda como membro do Capítulo Brasil do OWASP, do OWASP Global internet-nos-lares-brasileiros.
Education Committee na América Latina e voluntário no (ISC)2.

Referências
1. PCI Council em https://www.pcisecuritystandards.org/.
2. Entendendo o PCI: Porque os padrões promovidos pelo PCI
Council são bem mais que um simples snake oil em http://
www.scribd.com/doc/15235024/Entendendo-o-PCI.
3. Payment Processor Breach May Be Largest Ever em http://
voices.washingtonpost.com/securityfix/2009/01/
payment_processor_breach_may_b.html.
4. OWASP Top 10 2010 em http://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project.
5. Definição de Snake Oil na Wikipedia em http://en.wikipedia.org/
wiki/Snake_oil.
6. Responsabilidade Compartilhada em http://
www.conviso.com.br/responsabilidade-compartilhada/.
7. As três principais metodologias para o suporte a um SDL são The
Building Security In Maturity Model disponível em http://
bsimm2.com/index.php, Software Assurance Maturity Model
disponível em http://www.opensamm.org/ e Microsoft Security
Development Lifecycle disponível em http://www.microsoft.com/
security/sdl/default.aspx.
8. Sarbanes–Oxley Act na Wikipedia em http://en.wikipedia.org/
wiki/Sarbanes–Oxley_Act.

Conviso IT Security | White Papers | Porque o Requisito 6 do PCI DSS pode ser mais um Snake Oil 6