[Owasp-brazilian] BSIMM 2 PT-BR

Christian Heinrich christian.heinrich at owasp.org
Tue Oct 12 21:21:45 EDT 2010


Wagner and Fabricio,

I have commenced the correlation of BSIMM and OpenSAMM:

http://cmlh.id.au/post/1206230175/correlation-of-bsimm-domain-and-practice-to-opensamm-bus
- this has also been published to the OpenSAMM mailing list and to
Gary, Brian and Samy (i.e. main authors of BSIMM)

I should have the draft of this body of work published by the end of
2010 for comment if you are interested in providing feedback?

2010/10/13 Wagner Elias <wagner.elias at gmail.com>:
> Fabricio,
>
> primeiramente meus parabéns por mais uma grande iniciativa. Eu estava
> lendo o BSIMM e anotei algumas coisas no texto:
>
> 1 - Introdução - Página 1
>
> Até 2006, o ponto crítico de relacionado a segurança de software
> aconteceu com a publicação de dois livro descrevendo o tipo de
> atividades uma organização poderia realizar de modo a gerar software
> seguro (Software Security por McGraw e The Security Development
> Lifecycle por Howard e Lipner).
>
> Correção sugerida: Até 2006, o ponto crítico relacionado a
> segurança de software aconteceu com a publicação de dois livros
> descrevendo os tipos de atividades que uma organização poderia
> realizar de modo a gerar software seguro (Software Security por McGraw
> e The Security Development Lifecycle por Howard e Lipner).
>
> 2 - Criando o BSSIM pela observação - Página 6
>
>  Modelos prescritivos se propõem a informar o que deve ser feito.
> Porém, modelos se tornam prescritivos ao longo do tempo, a medida que
> se realiza observação e teste suficientes.
>
> Correção sugerida:  Modelos prescritivos se propõem a informar o que
> deve ser feito. Porém, modelos se tornam prescritivos ao longo do
> tempo, a medida que se realiza observações e testes suficientes.
>
> 3 - Criando o BSSIM pela observação - Página 6
>
> As cinco pequenas mudanças realizadas foram inteiramente guiadas
> pelos dados e observação e estão registradas em detalhes no
> Apêndice.
>
> Correção sugerida: As cinco pequenas mudanças realizadas foram
> inteiramente guiadas pelos dados e observações e estão registradas
> em detalhes no Apêndice.
>
> 4 - Objetivos - Página 7
>
> Você poderá adaptar as atividades sugeridas na sua organização
> (considerando cuidadosamente os objetivos que documentados).
>
> Correção sugerida: Você poderá adaptar as atividades sugeridas na
> sua organização (considerando cuidadosamente os objetivos
> documentados).
>
> 5 - Papéis - Página 8
>
> Determinar os responsáveis por conduzir as atividades do BSIMM é
> crítico rumo ao sucesso de uma iniciativa de segurança de software.
> Quando se apresenta à todas as linhas de frente envolvidas na
> iniciativa de segurança de software, estes parágrafos do Capítulo 1
> de Segurança de Software definem uma base para uma discussão
> aprofundada:
>
> Correção sugerida: Determinar os responsáveis por conduzir as
> atividades do BSIMM é uma atividade crítica rumo ao sucesso de uma
> iniciativa de segurança de software. Quando se apresenta à todas as
> linhas de frente envolvidas na iniciativa de segurança de software,
> estes parágrafos do Capítulo 1 de Segurança de Software definem uma
> base para uma discussão aprofundada:
>
> 6 - Papéis - Página 8
>
> Muitos praticantes de segurança hoje em dia têm o perfil de redes.
> São peritos em arquiteturas de rede, configura- ção de firewall e
> suporte à operação. Infelizmente, muitos deles possuem um
> entendimento rudimentar de software. Isso leva a adoção de
> tecnologias reativas fracas (ex. ferramentas de teste de segurança de
> aplicações). Ferramentas como esta focam no problema certo
> (software) com a solução inadequada (testes fora → dentro) .
>
> Correção sugerida: Muitos praticantes de segurança hoje em dia têm o
> perfil de redes. São peritos em arquiteturas de rede, configura-
> ção de firewall e suporte à operação. Infelizmente, muitos deles
> possuem um entendimento rudimentar de software. Isso leva a adoção
> de tecnologias fracas e reativas (ex. ferramentas de teste de
> segurança de aplicações). Ferramentas como estas focam no problema
> certo (software) com a solução inadequada (testes fora → dentro) .
> Obs.: Não ficou claro o fora -> dentro.
>
> 7 - O grupo de segurança de software - Página 9
>
> Entretanto, os melhores revisores de código, algumas vezes, são
> muito fracos arquitetos de software e solicitar a eles uma Análise de
> Risco de Arquitetura resultará será inócuo.
>
> Correção sugerida: Entretanto, os melhores revisores de código,
> algumas vezes, são arquitetos de software muito fracos e solicitar a
> eles uma Análise de Risco de Arquitetura resultará em algo inócuo.
>
> 8 - O framework de segurança de software - Página 14
>
> Implantação: Práticas que representam o elo de ligação entre o
> desenvolvimento e áreas de segurança de rede e manutenção de
> software. A configuração de software, a manutenção e outras
> questões de ambiente possuem impacto direto na segurança de
> software.
>
> Correção sugerida: Implantação: Práticas que representam o elo
> entre o desenvolvimento e áreas de segurança de rede e manutenção
> de software. A configuração de software, a manutenção e outras
> questões de ambiente possuem impacto direto na segurança de
> software.
>
> 9 - O framework de segurança de software - Página 15
>
> A prática padrões e requisitos envolve o levantamento explícito de
> requisitos de segurança pela organização, determinando quais COTS
> recomendar, construir padrões para os principais controles de
> segurança (como autenticação, validação de entrada, etc.),
> criando padrões de segurança para as tecnologias em uso e criando um
> corpo de revisão de padrões.
>
> Obs.: A frase ficou confusa e não encontrei no documento o que é o COTS.
>
> 10 - O framework de segurança de software - Página 15
>
> A prática teste de segurança se preocupa com testes anteriores ao
> lançamento, incluindo testes integrados de segurança seguindo
> processo padrão de garantia de qualidade.
>
> Correção sugerida: A prática de testes de segurança se preocupa com
> testes anteriores ao lançamento, incluindo testes integrados de
> segurança seguindo um  processo padrão de garantia de qualidade.
>
> 11 - BSIMM2 - Tabela na página 16
>
> Orientação prescritiva para cada interessado, autitabilidade
>
> Alterar autibilidade por auditabilidade
>
> 12 - GOVERNANÇA: Estratégia e Métricas (SM) - Página 18
>
> O SSG pode realizar palestra sinternas, estender convites para
> palestrantes externos, desenvolver artigos para consumo interno ou
> criar uma coleção de artigos, livros e outros recursos em um sítio
> interno.
>
> Alterar sinternas por internas
>
> 13 - GOVERNANÇA: Estratégia e Métricas (SM) - Página 19
>
> O satélite começa como um conjunto de pessoas pela organização que
> demon- stram um nível de interesse ou habilidade em segurança acima
> da média.
>
> Alterar o demon- sílaba separada errada.
>
> 14 - GOVERNANÇA: Estratégia e Métricas (SM) - Página 20
>
> É mencionado um acrônimo PII e não tem o seu significado.
>
> 15 - GOVERNANÇA: Estratégia e Métricas (SM) - Página 23
> consid- alterar para conside- :ram
>
> 16 - Inteligência - Modelos de ataque - Página 24
>
> con- hecimento sílaba separada errada.
>
> 17 - Inteligência - Modelos de ataque - Página 26
>
> A frase ficou confusa: O SSG deve estar disponível para e se capaz de
> resolver problemas de design para outros.
>
> 18 - Inteligência - Modelos de ataque - Página 27
>
> Implementadores devem escolher dentre os mecanismos e frameworka aprovados.
>
> Alterar framerko para framework.
>
> 19 - - Página 32
>
> O SSG realizar revisão de código ad hoc para aplicações de alto
> risco numa abordagem oportunísta.
>
> Correção sugerida: O SSG realiza revisão de código ad hoc para
> aplicações de alto risco numa abordagem oportunísta.
>
> 20 - Touchpoints - Página 32
>
> O SSG deve impor o uso de ferramentas centradalizadas de relatórios
> para capturar o conhecimento sobre bugs recorrentes e usar tal
> informação na estratégia e treinamento.
>
> Correção sugerida: O SSG deve impor o uso de ferramentas centralizadas
> de relatórios para capturar o conhecimento sobre bugs recorrentes e
> usar tal informação na estratégia e treinamento.
>
> 21 - Touchpoints - Página 33
>
> Quando um novo tipo de bug é encontrado, o SSG pode escrever regras
> para encontrá-lo, então localizar em no código todas as
> ocorrências.
>
> Correção sugerida: Quando um novo tipo de bug é encontrado, o SSG
> pode escrever regras para encontrá-lo, então localizar no código
> todas as ocorrências.
>
> 22 - Touchpoints - Página 34
>
> O time de QA estrapola o teste funcional para realizar testes básicos
> de segurança. Eles verificam casos simples de borda e condições de
> limite de fronteira.
>
> Correção sugerida: O time de QA extrapola o teste funcional para
> realizar testes básicos de segurança. Eles verificam casos simples
> de borda e condições de limite de fronteira.
>
> Abs.
>
> Em 28 de setembro de 2010 09:31, Fabricio Braz
> <fabricio.braz at gmail.com> escreveu:
>> Olá Pesso at l,
>>
>> Fizemos a tradução do modelo BSIMM para PT-BR.
>>
>> Detalhes http://tiny.cc/7jab9.
>>
>> Abraços,
>>
>> Fabrício Braz
>> _______________________________________________
>> Owasp-brazilian mailing list
>> Owasp-brazilian at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>>
>
>
>
> --
> Wagner Elias - OWASP Leader Project Brazil
> ------------------------------------------------------------------
> Twitter: www.twitter.com/welias
> Blog: http://wagnerelias.com
> Profile: http://www.linkedin.com/in/wagnerelias
> _______________________________________________
> Owasp-brazilian mailing list
> Owasp-brazilian at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>



-- 
Regards,
Christian Heinrich
http://www.owasp.org/index.php/user:cmlh


More information about the Owasp-brazilian mailing list