[MASOCH-L] Sipvicious

Durval Menezes durval at tmp.com.br
Fri Apr 25 17:00:48 BRT 2014 

Ola' Douglas,

On Fri, Apr 25, 2014 at 03:58:56PM -0300, Douglas Fischer wrote:
> 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?

Concordo com voce: na maior parte das empresas (onde impera um tipo
especial de miopia, veja o meu ultimo email), nao ha' respaldo/vontade
politica/comprometimento necessario para se implantar nada que nao seja
a solucao que exija o menor investimento, no sentido mais miope desta
palavra.

E, repetindo, acho que a forma como voce encara o problema e' bastante
pragmatica e pode ate' mesmo acabar implantando a "melhor" solucao, dentro
do que e' possivel dada esta miopia empresarial.

Mas, novamente, nao devemos perder de vista o porque desta realidade ser 
o que e'...

Um Grande Abraco,
-- 
  Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)


> 
> 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
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l

More information about the masoch-l mailing list