Saturday, March 14, 2009

(In)Segurança em Desenvolvimento de Software e o modelo BSIMM


[ 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 (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 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... =)

4 comments:

  1. A Adobe não é a única a deixar de corrigir vulnerabilidades "0-Day".

    Durante 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

    ReplyDelete
  2. Opa Nelson, tudo certo?

    Esta 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,

    ReplyDelete
  3. Nelson e S.S.:

    eu 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 =-

    ReplyDelete
  4. Sandro, obrigado... Tenho acompanhado seu Blog de perto e parabéns pelos artigos.

    A 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

    ReplyDelete