[ Update: 29/09/2010 ]
O Fabrício Braz divulgou sua tradução para o português do BSSIM:
[ Post Original: 14/03/2009 ]
O Marcelo Souza fez um post muito interessante sobre segurança em desenvolvimento e o modelo BSIMM, publicado por Gary McGraw, Brian Chess e Sammy Migues.
O BSIMM é um esforço de organização e categorização de um problema complicadíssimo que é o desafio em desenvolver, manter, comprar, integrar e utilizar softwares de forma segura. Isto é tão difícil que é necessário todo interesse, apoio, priorização e investimento para que uma empresa alcançe um nível real razoável em qualquer das 12 práticas dos 4 domínios do Software Security Framework (Governança, Inteligência, Ciclo de Desenvolvimento e Implementação). Para uma empresa grande e com processos viciados é quase como um idoso aprender a falar outra língua fluentemente - pode demorar décadas (que ele não viverá).
Isto nos mostra quão longe realmente estamos de uma melhora significativa, e quanto este esforço - apesar de louvável - tem como maior mérito a conscientização dos próprios responsáveis e envolvidos pela segurança do desenvolvimento de softwares, e talvez uma falsa sensação de segurança para quem tem o "seu" na reta (CSO, CIO, C[A-Z]O), que ficarão felizes com uma pontuação alta no BSSIM.
Se compararmos este cenário com a facilidade que um atacante - bem preparado, com tempo e alvo fixo em mente - consegue explorar falhas de design, implementação, configuração e/ou programação de um destes controles, entendemos o porque do uso do termo "guerra assimétrica" para descrever ataques perpetrados por hackers.
Parafraseando o Kevin Mitnick: Uma empresa precisa conhecer, encontrar e corrigir todos os erros de segurança (e ainda detectar, encontrar e tentar prender o atacante) , um hacker só precisa encontrar e explorar uma falha. Ou seja, do ponto de vista do atacante, 143 = 0.
E pra piorar, já que a "Alta Administração" não vai apoiar por falta de interesse, investimento, compreensão e prioridade, enquanto você não consegue se esmerar nas 110 atividades listadas, se prepare para continuar a responder a muitos incidentes de segurança e esteja com sua equipe de computação forense sempre a postos e bem treinada... =)
O Marcelo Souza fez um post muito interessante sobre segurança em desenvolvimento e o modelo BSIMM, publicado por Gary McGraw, Brian Chess e Sammy Migues.
"O BSIMM (Building Security In - Maturity Model), um modelo de maturidade focado em segurança de software. O modelo foi elaborado com base em iniciativas de segurança de 9 empresas diferentes, entre elas Adobe, EMC, Google e Microsoft. Utilizando um arcabouço de sua autoria denominado SSF (Software Security Framework), que aponta domínios e práticas comuns das iniciativas em segurança de software, o grupo conduziu pesquisas nas empresas participantes e utilizou os dados obtidos para construção do modelo.
O modelo lista 110 atividades divididas em 12 práticas dos 4 domínios do SSF. Cada prática pode receber até o nível 3 de maturidade. Totalmente livre (licença Creative Commons), o modelo pode ser obtido neste link (requer registro), ou acessado interativamente aqui."
Normalmente estes modelos são muito teóricos, mas o BSIMM me pareceu suficientemente específico e mais próximo da realidade. Me lembrou em certos aspectos os guias do NIST e do CERT, - cuidado você pode desanimar quando ler o primeiro ítem da lista: "Apoio da Alta Administração"...O BSIMM é um esforço de organização e categorização de um problema complicadíssimo que é o desafio em desenvolver, manter, comprar, integrar e utilizar softwares de forma segura. Isto é tão difícil que é necessário todo interesse, apoio, priorização e investimento para que uma empresa alcançe um nível real razoável em qualquer das 12 práticas dos 4 domínios do Software Security Framework (Governança, Inteligência, Ciclo de Desenvolvimento e Implementação). Para uma empresa grande e com processos viciados é quase como um idoso aprender a falar outra língua fluentemente - pode demorar décadas (que ele não viverá).
Segundo o BSSIM, uma medição máxima de "maturidade" do modelo seria 12*4*3 = 144. O perigo é que as pessoas tenderão a se basear nesta medida para considerar mais seguro um projeto/software/empresa que alcance uma pontuação alta em um assessment do BSSIM.
Isto funciona até o próximo deslize mínimo de uma destas empresas envolvidas que estão implementando o modelo e todos os esforços, conquista de "compliance" e melhores práticas ou "nível de maturidade" vão embora. Alguns exemplos: SDL Microsoft, ex-PCI da Heartland (obtido em Abril e revogado ontem), ou a metodologia de outros participantes do BSSIM - Adobe por exemplo - que deixou o Reader PDF sem correção crítica por 15 dias...
Isto funciona até o próximo deslize mínimo de uma destas empresas envolvidas que estão implementando o modelo e todos os esforços, conquista de "compliance" e melhores práticas ou "nível de maturidade" vão embora. Alguns exemplos: SDL Microsoft, ex-PCI da Heartland (obtido em Abril e revogado ontem), ou a metodologia de outros participantes do BSSIM - Adobe por exemplo - que deixou o Reader PDF sem correção crítica por 15 dias...
Isto nos mostra quão longe realmente estamos de uma melhora significativa, e quanto este esforço - apesar de louvável - tem como maior mérito a conscientização dos próprios responsáveis e envolvidos pela segurança do desenvolvimento de softwares, e talvez uma falsa sensação de segurança para quem tem o "seu" na reta (CSO, CIO, C[A-Z]O), que ficarão felizes com uma pontuação alta no BSSIM.
Se compararmos este cenário com a facilidade que um atacante - bem preparado, com tempo e alvo fixo em mente - consegue explorar falhas de design, implementação, configuração e/ou programação de um destes controles, entendemos o porque do uso do termo "guerra assimétrica" para descrever ataques perpetrados por hackers.
Parafraseando o Kevin Mitnick: Uma empresa precisa conhecer, encontrar e corrigir todos os erros de segurança (e ainda detectar, encontrar e tentar prender o atacante) , um hacker só precisa encontrar e explorar uma falha. Ou seja, do ponto de vista do atacante, 143 = 0.
E pra piorar, já que a "Alta Administração" não vai apoiar por falta de interesse, investimento, compreensão e prioridade, enquanto você não consegue se esmerar nas 110 atividades listadas, se prepare para continuar a responder a muitos incidentes de segurança e esteja com sua equipe de computação forense sempre a postos e bem treinada... =)
A Adobe não é a única a deixar de corrigir vulnerabilidades "0-Day".
ReplyDeleteDurante uma pesquisa - para um artigo em meu Blog - fiquei assustado com algumas vulnerabilidades "0-Day", pois mesmo após a sua descoberta passaram-se vários dias antes de uma correção ser liberada.
O mais incrível é que algumas nem sequer foram corrigidas. Veja você mesmo aqui.
@nbrito
Opa Nelson, tudo certo?
ReplyDeleteEsta lista de 0day eEye é esclarecedora mesmo..
PS: legal o início do post do "0-day" + "Heap Spray" = "Bad Day".. Já estou aguardando a continuação..
[ ]s,
Nelson e S.S.:
ReplyDeleteeu faço pen-tests como profissão,
há 5 anos, e posso afirmar: 0-day
não é o seu maior problema! o
buraco é muito mais embaixo (mais
fácil de alcançar). o 'Zero-Day'
talvez seja uma preocupação para
as RARAS empresas que podem se
gabar que as suas aplicações e
sistemas operacionais estejam
todos 'patcheados'! normalmente,
o uso de engenharia social e uma
ou duas vulnerabilidade 100-days
(a hundred days) é mais do que suficiente para ser invadido fácil
-= NetBorn =-
Sandro, obrigado... Tenho acompanhado seu Blog de perto e parabéns pelos artigos.
ReplyDeleteA segunda parte do "0-day" + "Heap Spray" = "Bad Day" já está em meu Blog.
NetBorn, olá...
Concordo que não é necessário um "0-Day" para realizar um Pen-Test, porém a questão maior é quanto ao mercado negro da venda destas vulnerabilidades... Porém entraremos em um assunto muito mais delicado e com vários desdobramentos!
@nbrito