[Owasp-brazilian] res: BSIMM 2 PT-BR

Fabricio Braz fabricio.braz at gmail.com
Wed Oct 13 09:53:23 EDT 2010


 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íticorumo 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/20101013/2a5a9469/attachment-0001.html 


More information about the Owasp-brazilian mailing list