[MASOCH-L] Sipvicious

Douglas Fischer fischerdouglas at gmail.com
Fri Apr 25 15:58:56 BRT 2014


Entendo o seu ponto de vista,
e concordo com boa parte dele.

Mas aí vem uma questão de respaldo.
- Quem é o seu cliente?
- Qual o impacto que uma falha de segurança pode gerar a ele e aos clientes
e fornecedores dele?
- Em concorrentes de seu cliente, quais são as praticas comuns?
- Você tem bala-na-agulha e cacique para peitar tal impacto caso algo
acontece?
- Tem alguém que pode corroborar/ratificar sua decisão?




Em 25 de abril de 2014 15:39, Durval Menezes <durval at tmp.com.br> escreveu:

> Prezado Douglas,
>
> On Fri, Apr 25, 2014 at 02:14:46PM -0300, Douglas Fischer wrote:
> [...]
> > Quando eu analiso o ambiente do cliente, e chego a conclus??o que o que
> cabe
> > melhor ali ?? uma solu????o de caixa fechada, um dos fatores que levo em
> > considera????o ?? justamente o c??digo ser fechado.
>
> Se nao olharmos estritamente para o aspecto de seguranca, eu concordo com
> voce
> que em alguns casos a solucao "fechada" pode atender melhor a um ou outro
> cliente
> (quando por exemplo a solucao aberta nao tem uma interface amigavel o
> suficiente,
> e o cliente nao quer investir na contratacao/formacao de empregados com
> nivel
> tecnico suficiente para operar a solucao aberta e com interface menos
> amigavel).
>
> Ou ainda, quando nao ha' solucao aberta que implemente determinada
> funcionalidade
> necessarias para o cliente com o nivel de estabilidade e desempenho
> necessarios,
> e ele nao tem tempo de esperar que a solucao aberta estabilize, nem esta'
> disposto
> a investir (seja via um "bounty", ou pagando consultores para
> customizar/depurar/otimizar a solucao opensource para o caso dele).
>
> Mas, friso, nunca vi uma situacao em que a solucao fechada fosse mais
> segura que
> a solucao aberta.
>
> > Vou exemplificar minha posi????o tomando como exemplo descoberta de novas
> > vulnerabilidades de seguran??a em solu????es.
> >
> > TODAS solu????es est??o sujeitas a vulnerabilidades de seguran??a.
> > Acho que disso ningu??m discorda, certo?
>
> Concordo que tanto solucoes abertas como fechadas podem conter
> vulnerabilidades;
> solucoes abertas, entretanto (devido `a Lei de Linus, que diz que "havendo
> olhos
> o bastante, todos os bugs sao rasos") as solucoes abertas tendem a ter
> seus bugs
> descobertos e resolvidos mais MUITO mais rapidamente do que nas fechadas.
>
> Assim, os bugs em solucoes abertas tendem a ser em menor numero, e a
> permanecerem
> por menos tempo, do que em solucoes fechadas.
>
> > Empresas como Checkpoint, Cisco, Palo-Alto, quando tem vulnerabilidades
> > identificadas em suas solu????es tem a pr??tica de INFORMAR
> INDIVIDUALMENTE
> > que est??o cadastrados como usu??rios daquela plataforma afetada ANTES DE
> > DIVULGAR PUBLICAMENTE A VULNERABILIDADE.
> >    P.S.: Da?? a import??ncia de manter um contrato
> >       de suporte com o fabricante, e l??gicamente
> >       manter seu cadastro devidamente atualizado
> >       por l??..
>
> Voce nao deve ter prestado atencao ao meu ponto no email anterior;
> repetindo aqui: quando o bug em um produto fechado fica "escondido" por
> conta de um "conchavo" entre o fabricante e a NSA (ou outra "autoridade"
> qualquer) ele nao e' consertado (e muito menos informado a ninguem) ate'
> que ele seja descoberto e explorado por um terceiro.
>
> > Quando se usa ferramentas OpenSource, a informa????o sobre a
> vulnerabilidade
> > chega ao mesmo tempo na m??o do administrador do ambiente e do poss??vel
> > intrusor, o que dispara uma corrida entre corrigir e atacar(Haja vista o
> > HeartBleed).
>
> Isso nao e' geralmente verdade: o procedimento responsavel de "disclosure"
> de bugs de seguranca manda primeiro avisar ao responsavel (seja o time de
> desenvolvimento do produto aberto, seja o fabricante do produto fechado),
> e somente apos um prazo "razoavel" (mais do que suficiente para o problema
> ser sanado) tornar a informacao publica.
>
> O que aconteceu no caso do Heartbleed foi um certo "estrelismo" (IMNSHO) do
> pessoal da Codenomicon, que menos de 4 dias apos terem descoberto (e
> reportado
> de forma inicialmente responsavel, via CERT-FI) o bug, resolveram tornar a
> informacao publicamente disponivel antes da equipe de desenvolvimento do
> OpenSSL
> (que ja' tinha recebido a informacao da falha, bem como um patch para a sua
> correcao, ha' mais de 15 dias da equipe do Google que descobriu
> originalmente
> o problema) ter tempo de terminar de fazer o release da versao
> incorporando a
> correcao, e menos ainda das distribuicoes atualizares seus pacotes para a
> nova
> versao e os disseminarem.
>
> Veja que o caso do Heartbleed, alem de poder ter acontecido de forma
> semelhante
> tambem com produtos de software fechado (como de fato acontece com
> bastante frequencia), foi uma excecao: a grande maioria dos problemas de
> seguranca em produtos abertos sao descobertos, reportados privativamente,
> corrigidos e disseminados muito antes de serem explorados. Nao e' o que
> vemos nos produtos fechados, onde notadamente a exploracao do problema
> chega muito antes da sua solucao pelo fabricante (e' so' observar o
> fracasso de seguranca constante que e' o Windows).
>
> Isso, e' claro, trata-se somente da minha opiniao, mas acredito que seja
> uma
> opiniao bem fundamentada...
>
> Um Grande Abraco,
> --
>   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
>
>
> >
> > Em 25 de abril de 2014 13:25, Durval Menezes <durval at tmp.com.br>
> escreveu:
> >
> > > Prezados,
> > >
> > > Desculpem-me, mas discordo de ambas as posicoes; a saber:
> > >
> > > Douglas: o que voce diz muito se parece com a velha posicao de que
> > >          "ninguem nunca foi mandado embora por comprar da IBM".
> > >          Com todo o respeito (e ressalvando que nao acredito que tenha
> > >          sido isso que que voce tenha *querido* dizer), esta e' uma
> > >          posicao mediocre de quem esta' tentando somente proteger o
> > >          proprio traseiro, nada digna de tecnicos como nos, que
> > >          frequentamos o MASOCH-L.
> > >
> > > Bruno: ninguem garante que *somente* a NSA saiba; se o furo esta' la',
> > >        e' questao de tempo ate' ser descoberto por alguem que ira'
> vender
> > >        a falha no mercado de "zero days" para o proximo ataque em massa
> > >        a la Zeus ou similar. Questoes de privacidade `a parte, na minha
> > >        opiniao o grande problema do "conchavo" entre os fabricantes de
> > >        produtos fechados e a NSA e' que ele praticamente garante que
> > >        os problemas vao permanecer no codigo eternamente enquanto nao
> > >        forem descobertos (e utilizados) por terceiros... o que IMNSHO
> > >        mais uma vez demonstra que nao e' possivel construir estruturas
> > >        de informacao realmente seguras utilizando produtos fechados.
> > >
> > > Um Grande Abraco,
> > > --
> > >   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/
> )
> > >
> > >
> > > On Fri, Apr 25, 2014 at 12:04:44PM -0300, Douglas Fischer wrote:
> > > > Assim...
> > > >
> > > > Eu n??o acho que a NSA precise usar meu SIP Session Manager p/ vender
> > > > liga????es VOIP Piratas.
> > > >
> > > > E se o Router que eu especifiquei e configurei for hackeado pela NSA,
> > > > atrav??s de supostas backdoors impostas ao fabricante, bom... Meu
> > > trabalho
> > > > foi bem feito!
> > > > N??o ser?? uma vergonha para mim.
> > > >
> > > > Mas se eu especificar uma distro X, deixar passar algum furo, e algum
> > > > noobie usando Cain e Abel conseguir entrar nela, meu filme vai ficar
> bem
> > > > tostado...
> > > >
> > > >
> > > >
> > > > Em 25 de abril de 2014 11:48, Bruno Cabral <bruno at openline.com.br>
> > > escreveu:
> > > >
> > > > > Aquelas que os furos apenas a NSA sabe...
> > > > >
> > > > > !3runo
> > > > >
> > > > >
> > > > > > Por isso eu amo appliances...
> > > > > >
> > > > > > Appliances MESMO, n??o distro customizadas.
> > > > > > Aquelas onde tudo ?? chrootado, onde a console ?? limitada, onde
> > > tudo ??
> > > > > > capado...
> > > > >
> > > > > __
> > > > > masoch-l list
> > > > > https://eng.registro.br/mailman/listinfo/masoch-l
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Douglas Fernando Fischer
> > > > Eng?? de Controle e Automa????o
> > > > __
> > > > masoch-l list
> > > > https://eng.registro.br/mailman/listinfo/masoch-l
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Eng?? de Controle e Automa????o
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação


More information about the masoch-l mailing list