O Bug Heartbleed (e é definitivamente um bug - não um vírus) desencadeou um debate em torno da segurança e confiabilidade do software de código aberto nos últimos meses.

Descoberto por pesquisadores do Google e Codenomicon, a vulnerabilidade foi encontrada na biblioteca de software criptográfico OpenSSL que fornece proteção SSL (Secure Sockets Layer) e TSL (Transport Layer Security) para qualquer coisa, desde e-mails e navegação na Internet até serviços bancários via Internet..

O erro de programação que levou ao Heartbleed - que foi acidentalmente introduzido pelo programador alemão Dr. Robin Seggelmann, um colaborador frequente do código OpenSSL - permite que os atacantes baixem 64k de dados armazenados na memória principal supostamente segura dos servidores..

Foi um erro honesto, mas com consequências de longo alcance. De acordo com a Errata Security, cerca de 320.000 dos 600.000 servidores vulneráveis ​​detectados ainda estão vulneráveis ​​ao Heartbleed.

Post-Heartbleed, todas as chaves privadas em servidores que executam o OpenSSL agora são suspeitas e podem ser potencialmente usadas por invasores para representar sites seguros, desde que esses servidores permaneçam sem correção.

É hora de mudar do OpenSSL para uma solução comercial (ou outra alternativa) quando se trata de segurança na web? Conversamos com especialistas do setor na Infosec 2014 para saber mais.

Mantenha o código aberto - ele ainda tem muito a oferecer…

James Sherlow, Gerente de SE da WEO na Palo Alto Networks, acha que abandonar o OpenSSL na esteira do Heartbleed seria uma reação instintiva:

"O OpenSSL ainda é altamente relevante e tem escalabilidade. Ele tem uma comunidade de desenvolvedores altamente qualificados, que é extremamente valiosa e ainda é válida. Todo software em um determinado momento terá algum tipo de vulnerabilidade associada a ele, mas não significa que nós desligamos, isso significa que aprendemos com nossas lições ".

… Mas Heartbleed foi um alerta

"Eu acho que a comunidade de código aberto precisa começar a colocar mecanismos em diferentes áreas que possam cruzar os outros. Isso é melhor do que apontar e culpar que não leva ninguém a lugar nenhum. Isso mitigaria o risco, reduziria a chance de ataque e Para chegar a zero erros é difícil, mas vamos apontar para ele. Essa é a barra. "

Você não poderia simplesmente desfazer isso de qualquer maneira ...

A questão de saber se devemos nos livrar do OpenSSL não é tão em preto-e-branco, de acordo com JD Sherry, vice-presidente de Tecnologia e Soluções da Trend Micro. Ele acredita que, em vez de recusar os serviços de colaboradores dedicados e talentosos de código aberto, recompensas devem ser oferecidas a outros que buscam erros em seu trabalho:

"O código aberto sempre será uma parte inata do que fazemos, principalmente porque há muita engenharia envolvida nisso - muitas pessoas dedicam sua paixão a esses projetos e muito trabalho excelente vem deles."

… Então vamos introduzir mais recompensas de bugs

"Empresas como Google, Microsoft e Facebook se juntaram para despejar US $ 100 mil cada para chegar ao coração de Heartbleed, o que não é suficiente para impedir um cenário potencialmente similar. Recompensas por bugs, por outro lado, devem se auto-regular a questão do bug, e eles podem ser extremamente importantes.

"O custo de implementar e pagar por eles pode valer a pena o resultado que vem com uma grande falha em seu software que foi perdida durante o processo de controle de qualidade. Se código aberto ou não, eles serão críticos para garantir nós não temos uma quantidade enorme de Heartbleed ou outros casos do OpenSSL. "

O OpenSSL foi quebrado desde o início ...

Nem todo mundo tem sido tão indulgente quando se trata de OpenSSL. O FreeBSD e o desenvolvedor de segurança Poul-Henning Kamp chamaram sua atenção em um post no blog intitulado O Open SSL deve morrer, pois nunca ficará melhor:

"E isso me traz de volta ao OpenSSL - o que é uma droga. O código é uma bagunça, a documentação é enganosa e os padrões são enganosos. Além disso, são 300.000 linhas de código que sofrem de quase todas as doenças de engenharia de software que você possa imaginar."