[Owasp-brazilian] BSIMM 2 PT-BR

Fabricio Braz fabricio.braz at gmail.com
Fri Jan 14 08:06:25 EST 2011


Olá Pessoal,

Enquando a equipe do BSIMM não divulga a versão em PTBR com as correções
registradas nessa thread, além de outras tantas, os interessados podem fazer
o download do documento nesse link:

http://www.streamfile.com/myid/E1EfL88klXB1

Abraços,

Fabricio Braz, PhD

2010/10/13 Fabricio Braz <fabricio.braz at gmail.com>

>  Olá Wagner,
>
> Obrigado pela ampla revisão.
>
> Seguem abaixo minhas considerações.
>
> Abraço,
>
> Fabricio Braz
>
> ###############
>
>
> Antes de entrar nas questões levantadas, faço algumas ressalvas:
>
> ·         O Adobe InDesign não permitiu revisão gramatical/ortográfica.
> Considerando que toda revisão foi realizada manualmente, é passível que
> outros erros ainda existam, como, por exemplo, o erro de separação silábica.
>
> ·         As marcações em vermelho destacam os erros, as verdes as
> correções e em azul meus comentários.
>
> ·         Como o processo de publicação pela Cigital pode demorar mais do
> que o desejado, recomendo que considerem a revisão abaixo, até que isso
> aconteça.
>
>
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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 5 –
>
> 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.
>
> A expressão realmente se mostra obscura e, para que seja compreendida, é
> essencial fazer uma sua associação com a premissa básica do defendida pelo
> BSIMM que é pensar a segurança desde o conceito do software
> (in/dentro-dentro do ciclo de desenvolvimento) e depois que ele for liberado
> para uso (outside/fora-fora do ciclo de desenvolvimento).
>
>
>
> 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
>
> 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
>
> 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.
>
> Correção
>
> A prática Padrões e Requisitos envolve o levantamento explícito de
> requisitos de segurança pela organização, o levantamento dos componentes de
> terceiros recomendados, a elaboração de padrões para os principais controles
> de segurança (como autenticação, validação de entrada, etc.), a criação
> de padrões de segurança para as tecnologias em uso, e a criação de uma
> equipe para revisar os padrões.
>
> Obs.: A frase ficou confusa e não encontrei no documento o que é o COTS
>
> Commercial Off-The-Shelf – entendo por componentes de terceiros.
>
>
>
> 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
>
> Correção
>
> 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.
>
> Correção
>
> Alterar palestra sinternas por palestras 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.
>
> Correção
>
> 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.
>
> O significado é apresentado apenas na página 17:
>
> A maneira como o software manipula informações de cunho pessoal (sigla em
> inglês PII)
>
> Foi a tradução para “personally identifable information”.
>
>
>
> 15 - GOVERNANÇA: Estratégia e Métricas (SM) - Página 23
>
> consid- alterar para conside- :ram
>
> Só encontrei a ocorrência na página 20
>
>
>
> 16 - Inteligência - Modelos de ataque - Página 21
>
> con- hecimento sílaba separada errada.
>
> Só encontrei a ocorrência na página 21
>
>
>
> 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.
>
> Correção
>
> O SSG deve se mostrar disponível e ser capaz de resolver problemas afetos a
> fase de projeto.
>
>
>
> 18 - Inteligência - Modelos de ataque - Página 27
>
> Implementadores devem escolher dentre os mecanismos e frameworka aprovados.
>
> Correção
>
> 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
>
> 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
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-brazilian/attachments/20110114/9b9aa456/attachment-0001.html 


More information about the Owasp-brazilian mailing list