[Owasp-brazilian] [Owasp-brazilian-leaders] Segurança na web - Uma janela de oportunidades

Fernando Cima (SCOE) fcima at microsoft.com
Mon Apr 11 14:56:58 EDT 2011


Oi Thiago,


Ø  É verdade, mas isso também é relativo. Segurança geralmente faz parte dos requisitos não funcionais em uma especificação de projeto de software.


Ø  No caso dos problemas que afetam o desempenho dos requisitos não funcionais, eu acho que tudo é uma questão de comprovar o dolo. Se houve intenção de fazer, provavelmente existe a responsabilidade. Ex: um desenvolvedor que colocar um backdoor em um sistema provavelmente vai responder objetivamente.

Acho que não é isso que está se propondo aqui. Se o que se propõe é ter uma agência que defina critérios de segurança de software pelo qual existiria responsabilidade solidária das empresas desenvolvedoras em caso de não cumprimento, estes critérios vão precisar ser objetivos, verificáveis e universais. Eu adoraria ver como seriam tais critérios - temo que acabaríamos vendo algo similar a Common Criteria :(


Ø  Enfim, como diria um amigo advogado: a pior coisa do direito são os leigos que pensam que entendem de direito. Eu sou um deles (leigos) e peço desculpas se cometi alguma gafe :)

:) Fica tranquilo, pior são os advogados que pensam que entendem de segurança de software...

Cheers,


-          Fernando Cima

From: Thiago Zaninotti [mailto:thiago at zaninotti.net]
Sent: Wednesday, April 06, 2011 8:15 PM
To: Fernando Cima (SCOE)
Cc: owasp-brazilian at lists.owasp.org
Subject: Re: [Owasp-brazilian] [Owasp-brazilian-leaders] Segurança na web - Uma janela de oportunidades

Grande Cima,
2011/4/6 Fernando Cima (SCOE) <fcima at microsoft.com<mailto:fcima at microsoft.com>>

Está também se ignorando que o conceito de vulnerabilidade de segurança é diferente do conceito tradicional de defeito de software. Um software pode se comportar exatamente como definido na sua especificação (e portanto no sentido tradicional estar "correto"), mas ainda assim estar vulnerável.

É verdade, mas isso também é relativo. Segurança geralmente faz parte dos requisitos não funcionais em uma especificação de projeto de software.


 Por exemplo, um software com um buffer overflow pode tranquilamente implementar corretamente todos os use cases previstos na sua especificação funcional. No entanto ele implementa um "funcionalidade" adicional (o buffer overflow) indesejada que não deveria estar lá, e que jamais seria acionada caso não existisse um oponente agindo intencionalmente para causar dano. De quem deve ser a responsabilidade civil aqui? Para mim é do oponente e não do fabricante, que não tem condições de testar todos as use cases possíveis fora das suas especificações.


Por outro lado, se a segurança for um aspecto não funcional que fundamenta uma funcionalidade (i.e: uma função criptográfica para validação da autorização de cartões de crédito), acredito que o fabricante pode ser facilmente responsabilizado se o algoritmo falhar.

No caso dos problemas que afetam o desempenho dos requisitos não funcionais, eu acho que tudo é uma questão de comprovar o dolo. Se houve intenção de fazer, provavelmente existe a responsabilidade. Ex: um desenvolvedor que colocar um backdoor em um sistema provavelmente vai responder objetivamente.


É preciso também levar em conta que durante o desenvolvimento de um software decisões de gerência de risco são tomadas assumindo um determindo perfil de ameaças. No exemplo que eu dei anteriormente, um sistema de gerência de conteúdo voltado para blogs pessoais pode perfeitamente armazenas as suas senhas em claro no banco de dados, enquanto isto seria inimaginável em um sistema corporativo ou militar. Não existe um modelo "one-size-fits-all".

Concordo plenamente. O maior problema é a função de gestão de risco que, na maioria das vezes, não é feita sob a ótica dos requisitos formais de segurança demandados pelo próprio requisitante do sistema (proprietário).

Existe um artigo bem interessante da UFPE sobre requisitos formais de segurança para aplicações (Assad et al.):
http://www.computer.org/portal/web/csdl/doi/10.1109/ICSEA.2010.48


 Existem ainda situações onde determinadas "vulnerabilidades" tem que ser adotadas por questão de compatibilidade com o legado e/ou com padrões em vigor. Por exemplo, o Windows suporta o uso de certificados com hash MD5 devido ao número destes certificados em uso atualmente, ainda que o algoritmo seja atualmente considerado vulnerável. Como fica a responsabilidade aqui?


Creio que, neste caso, trata-se mais uma vez de uma questão de dolo. Se o sistema possui documentação necessária para informar o usuário sobre seus "KNOWN ISSUES", não creio que existem responsabilidades para o fabricante. A decisão de utilizar o software sempre será do usuário, portanto, ciente dos problemas.

Em um cenário que o uso de MD5 é obscuro e não informado e, por alguma limitação regulatória o usuário não possa utilizar o algoritmo, o fabricante possivelmente poderá ser responsabilizado.

Enfim, como diria um amigo advogado: a pior coisa do direito são os leigos que pensam que entendem de direito. Eu sou um deles (leigos) e peço desculpas se cometi alguma gafe :)

Abraços,

Thiago Zaninotti,Security+,CISSP-ISSAP,CISM,CSSLP
Restless Infosec & C/C++ Engineer


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-brazilian/attachments/20110411/d75aeb3c/attachment.html 


More information about the Owasp-brazilian mailing list