A OWASP é uma das melhores fontes de conhecimento para todos os profissionais que desejam trabalhar com desenvolvimento de software, e de quebra, ter um conhecimento robusto em melhores práticas de desenvolvimento seguro. Dentro dos projetos da OWASP, usamos muito o SAMM, criado como um modelo de maturidade para quem deseja entender e melhorar o seu processo de desenvolvimento. No entanto, existem outros modelos, também muito bons e com um ótimo histórico, como é o caso do BSIMM. Neste artigo, vamos abordar como se comparam os modelos SAMM e BSIMM.
Você também pode ouvir esse conteúdo:
Na Conviso, o SAMM é a base para muitas coisas que fazemos e recomendamos. Além disso, entendemos que hoje é um dos modelos mais maduros e efetivos que podemos encontrar no mercado. No entanto, não é o único.
É importante ressaltar que a intenção não é mostrar superioridade de um ou de outro – afinal, ambos podem ser usados boas fontes de estudos. O que queremos aqui é mostrar outras possibilidades, outros pontos de vista.
BSIMM
Em nossos posts anteriores já falamos bastante sobre o SAMM, e por isso queremos sugerir que você leia nossas artigos anteriores, isso pode ajudar a entender melhor como o SAMM pode ser usado. Além disso temos uma série de artigos sendo muito bem apresentadas pelo Wagner Elias, outra sugestão de leitura.
Vamos focar no BSIMM.
Bem, o BSSIM – Building Security In Maturity Model – este ano está em sua 10ª interação. Ele está com algumas mudanças, mas mantendo toda a sua base e conhecimento, quem ainda não conhece é bom ler sobre este modelo.
Mas o que é o BSIMM ? Se pegarmos a sua própria descrição, em tradução livre, teremos:
“É um estudo sobre iniciativas de segurança já existentes. Quantificando as práticas de muitas organizações diferentes, podemos descrever um terreno comum compartilhado por algumas bem como a variação que as torna únicas. O BSIMM não é um how-to ou mesmo uma receita de bolo. Em vez disso, é um reflexo da segurança de softwares.”
Assim como outros modelos, o BSIMM tenta trazer para o mercado as melhores práticas, bem como o entendimento do que pode e o que não pode funcionar. Afinal, tratam-se de práticas avaliadas e validadas no decorrer do tempo.
O BSIMM é um framework formado pela experiência de 122 empresas que participam do estudo e que estão ligadas a diferentes mercados, justamente para alcançar uma visão mais abrangente.
Como modelo, o BSIMM é formado por 119 atividades agrupadas em 4 grandes visões de uma empresa. São elas: Governance, Intelligence, SSDL Touchpoints e Deployment, como pode ser visto na imagem abaixo.
Então, o BSIMM se assemelha bastante a outros frameworks de avaliação de processos, tendo sempre uma base de práticas relacionadas a etapas ou mesmo áreas de uma organização.
Desta forma, podemos comparar essa organização com a do OWASP SAMM. Reforçando: aqui nossa intenção não é colocar uma avaliação de efetividades, dizer qual é melhor, queremos entender as semelhanças entre eles. Mesmo porque o uso de um ou de outro modelo vai depender muito da organização que vai implementar as práticas.
O que o SAMM e o BSIMM têm em comum
Como já mencionamos, em termos de estrutura os dois modelos se parecem muito. No entanto, existem, sim, diferenças. Uma das principais é que o BSIMM é um modelo descritivo, enquanto o SAMM é um modelo prescritivo. Vamos explicar.
Por ser um modelo descritivo, o BSIMM é um framework que mostra como os participantes estão aplicando práticas de segurança em seus processos de desenvolvimento. Já o SAMM é um modelo prescritivo e sua construção apresenta como uma organização pode ter mais segurança em seu processo de desenvolvimento.
O modelo de formação dos dados do BSIMM é formado por um processo de avaliação e entrevistas, com mais de 100 empresas que participam do projeto. Neste décimo ano, foi um total de 122 empresas participantes. Já o SAMM passa por um processo de avaliação interna dos times de projetos da OWASP, que com base nas experiências e avaliações de mercado criam e avaliam a eficácia das atividades sugeridas no modelo.
Ilustrando
Como podemos ver na imagem acima, o BSIMM guarda uma semelhança muito grande com a estrutura do OWASP SAMM, que também possui um conceito de divisão baseado em grande áreas de atuação organizacional. Guardam algumas diferenças quanto a isso, pois nesta última versão do SAMM, passamos de 4 para 5 grandes áreas.
Esta mudança trazida pela nova versão do SAMM foi realmente uma melhoria relevante para o modelo. Foram colocados em evidência processos que de certa forma já existiam nas versões anteriores, mas que agora estão separados e com suas próprios atividades relacionadas.
Como podemos notar, existem grandes semelhanças entre as estruturas, e conseguimos até mesmo relacionar umas às outras. Isso inclusive nos possibilita usar os dois modelos ao mesmo tempo, isso visto que um é um modelo descritivo e outro prescritivo.
De forma geral, podemos usar o BSIMM para entender como as empresas estão buscando introduzir segurança em seus processos. Já o SAMM pode nos ajudar a entender como podemos melhorar o nível de segurança de nossos produtos.
Abaixo vamos tentar manter um correlacionamento entre os dois modelos, buscando apresentar as semelhanças dentro das duas estruturas. Assim, isso pode ajudar na hora de visualizar como usar estes dois grandes modelos.
Vamos falar um pouco sobre estes relacionamentos mas, para manter um ponto de referência, vamos usar o SAMM como este ponto de apoio e, a partir dele, traçar as semelhanças.
Para tornar o artigo mais prático e não tão extenso, não vamos nos focar em mostrar ponto a ponto cada uma das práticas internas de cada área. No entanto, vamos tratar de suas semelhanças e diferenças de forma macro. Mas fica o convite para o leitor buscar os detalhes em cada um de modelos de forma mais pessoal.
SAMM – Governance
Neste primeiro momento, vamos tentar entender o que cada uma modelo traz como objetivo para esta área.
Para o SAMM, a área de Governance tem como foco principal entender como a organização gerencia suas atividades gerais de produção de aplicações seguras. Um olhar para grupos multifuncionais e para processos de negócios é que está no foco destas atividades relacionadas à Governance, e para o SAMM, um programa de desenvolvimento sem um plano definido é apenas perda de tempo.
Essa visão do SAMM sobre Governance é bem semelhante à do BSIMM.
Na declaração do BSIMM:
“Governance includes those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.”, ou seja:
“Governança inclui estas práticas para ajudar a organizar, gerenciar e mensurar as iniciativas de segurança de software. O desenvolvimento das pessoas também é um ponto central da Governance ”
Então, se voltarmos para a imagem acima, vamos poder notar que as 3 áreas de Governance do SAMM estão diretamente relacionadas com as as 3 áreas do BSIMM, inclusive com uma semelhança muito grande entre seus objetivos.
Além destas relações diretas entre as áreas de Governance dos dois modelos, Governance do SAMM, mas especificamente “Compliance & Policies” mantém uma correlação com a prática de “Standards & Requirements” do BSIMM.
Do SAMM, temos que a prática de “Compliance & Policies” tem como foco entender quais são os requisitos e regulamentos externos, e também internos, que devem ser seguidos pelas aplicações que serão construídos. Já a sua contraparte do BSIMM tem como foco entender os requisitos explícitos de segurança, além de criar padrões que devem ser seguidos pelas equipes de desenvolvimento na hora de construção de seus softwares.
SAMM – Design
Novamente temos as três práticas desta área se relacionando diretamente com outras áreas no BSIMM. Aqui não há um correlação entre áreas macro, mas há sim este relacionamento com práticas nos dois modelos.
A prática do SAMM chamada de “Threat Assessment ”, que está focada na identificação e compreensão dos riscos do projeto, com base nas suas funcionalidade e nas características do ambiente, agora em tempo de execução.
Se tomarmos como base esta descrição de objetivo, veremos que a prática de “Attack Models” do BSIMM possui um foco semelhante. Não diferente de outra relação com a prática de “Architecture Analysis”, que também usa métodos de Modelagem de Ameaças para identificar, e a posterior criação de um plano de remediação.
Continuando, podemos ver que a prática do SAMM de “Security Requirements” está ligada à prática de “Standards & Requirements”, pois ambas buscam como objetivos estabelecer padrões de segurança para que a aplicação possa seguir, criando assim um contexto de segurança dentro do seu desenvolvimento.
Como última prática desta área do SAMM, “Security Architecture” possui uma ligação com uma prática semelhante no BSIMM chamada de “Security Features & Design” que foca na construção de alguns padrões que definirão os principais controles de segurança. Está prática do BSIMM também está diretamente relacionada a outra prática, também do BSIMM, a “Standards and Requirements”. Uma dupla correlação para esta prática.
SAMM – Implementation
Nesta área do SAMM, temos apenas duas práticas que se relacionam com outras no BSIMM, deixando de fora desta comparação a prática de “Secure Build”, então vamos nos focar nas outras duas práticas.
A prática de “Secure Deployment” possui seu foco em garantir que a entrega do produto final do desenvolvimento seja feita de forma segura e íntegra. Isso visa garantir que não houve qualquer alteração não autorizada no código durante a sua passagem pelo pipeline de desenvolvimento.
Agora, se olharmos para a prática de “Software Environment” no BSIMM, veremos que seu foco está diretamente relacionado com a garantia de segurança para o software, olhando para todos os componentes que permitem que este seja executado, usado e entregue de forma segura.
Outra prática do SAMM, a “Defect Management”, visa registrar, analisar e coletar no software erros e defeitos, permitindo assim que depois seja possível a sua análise. Esta prática está relacionada com a “Configuration Management & Vulnerability Management” do BSIMM. Esta prática está também relacionada com a necessidade de entender e buscar analisar os erros dentro da estrutura, realizando da melhor forma possível suas correções.
SAMM – Verification
Quando analisamos a prática de “Architecture Assessment ” do SAMM, pensamos em como está prática está focada em garantir que a arquitetura e a infraestrutura estão atendendo a todos os requisitos de segurança de forma adequada.
As atividades desta prática estão relacionadas tanto com as atividades das práticas de “SSDL Touchpoints” quanto “Deployment” do modelo BSIMM.
A atividade de “Architecture Assessment” pode ser mapeada para a atividade de “Architecture Analysis”, e como já vimos em outra correlação, esta atividade tem como foco ajudar na identificação de ameaças por meio de alguns métodos. Um deles pode ser o uso de uma modelagem de ameaças.
Já a atividade de “Security Testing”, do SAMM, pode ajudar a complementar as atividades de “Code Review” e “Security Testing” do BSIMM, tendo objetivos bem semelhantes quando olhamos para o conjunto como um todo.
Claro que dificilmente teremos uma correlação exata de objetivos e atividades mas, se buscarmos entender o objetivo de cada uma das atividades dos modelos poderemos entender estas suas correlações.
A última atividade da prática de “Verification” do SAMM é “Requirements-driven Testing” e caso você venha a ter a curiosidade de ler seu objetivo, vai perceber que pode muito bem ser mapeado para a prática de “Deployment”, mas precisamente em sua atividade de “Penetration Test”.
Este mapeamento é feito porque o seu maior objetivo é buscar por falhas do software já operacional, e a realização de testes de intrusão é um, mas não o único teste a ser realizado.
SAMM – Operation
Essa prática do SAMM é a que menos possui correlação com práticas do BSIMM.
Do SAMM, apenas a atividade de “Environment Management” possui relação com seu par no BSIMM, neste chamada de “Software Environment”. Ambas, de forma geral, têm como foco olhar para a estrutura que dá suporte à aplicação e buscar construir da melhor forma possível uma base segura para que esta aplicação possa atuar.
Neste caso, ambas possuem como foco o stack de tecnologia, e buscar manter este stack o mais seguro possível, mantendo sistemas operacionais atualizados, tecnologias bem configuradas e disposta da melhor forma possível. Tudo para entregar à aplicação um local seguro para suas operações.
Nesta prática do SAMM as outras atividades não possuem uma relação direta no BSIMM, mas isso não quer dizer que as atividades de ambos os modelos que não estão correlacionados não tenham importância. Elas apenas possuem focos diferentes entre si.
Saiba mais sobre nossos serviços de Consultoria
Conclusão
Com este artigo tentamos mostrar que podem existir outras possibilidades que podem ser avaliadas para que possam usar em seus projetos.
Tentamos mostrar que, caso não tenha se dado bem com o SAMM por algum motivo, existem outras opções. O BSIMM é apenas uma delas, existem ainda outras – mas isso é tema para um próximo artigo.
Queremos agora entender como e com o que está avaliando seu processo de desenvolvimento seguro. Conte por meio dos comentários ou de nossas redes sociais como anda a sua experiência com modelos de maturidade.
Nos vemos no próximo artigo.
