Especialistas em segurança da informação de todo o mundo têm propagado o chamado Heartbleed como uma das falhas de segurança mais perigosas a atingir a web nos últimos tempos. Embora ainda não saibamos a extensão completa do Heartbleed, o bug tem potencial para causar perdas de dados catastróficas.
Quando as notícias sobre o Heartbleed surgiram, usuários da web foram aconselhados a mudar todas as senhas por precaução, e a TI corporativa deslocou seu pessoal de segurança para neutralizar a ameaça de forma imediata aplicando atualizações emergenciais. Mas assim como diversas situações complexas, o verdadeiro perigo desta ameaça está na atividade de longo prazo, quando ela começa a agir de forma mais cautelosa e silenciosa.
Como o bug foi embarcado na biblioteca de criptografia open source OpenSSL, usado por muitos servidores web, milhões de pessoas foram potencialmente afetadas. Mas o que torna o Heartbleed difícil de combater é que nós apenas sabemos que o dado foi exposto. Ainda não sabemos muito o quanto isso foi comprometido.
Open source está aqui para ficar
O uso de código open source tem sido bastante debatido pela comunidade de tecnologia. E ainda que o Heartbleed tenha exposto o risco inerente ao uso desse tipo de codificação, seria um grande erro descontinuar aplicações escritas em código aberto por conta deste bug.
Mesmo em plataformas fechadas e proprietárias, sérias vulnerabilidades são descobertas, e frequentemente pelo fato de as pessoas não aplicarem as atualizações para ameaças conhecidas. Existem cases bem documentados sobre incidentes de segurança de dados acontecendo anos depois de uma atualizações ter sido lançada para combater um bug conhecido.
Uma abordagem open source traz benefícios enormes, como implantação facilitada e compatibilidade com múltiplas plataformas. Assim como fabricantes de automóveis focam no design do veículo e deixam a fabricação de peças para terceiros, os desenvolvedores tendem a focar na criação do software e optam por ferramentas open source para tornar tráfego, senha e outros dados transmitidos mais seguros.
Ação e liderança necessárias
O Heartbleed é, na verdade, um grande despertador. Apesar de muitos desenvolvedores e usuários focarem em soluções ágeis disponíveis neste momento (mudança de senhas e pacotes de atualizações, por exemplo), o grande problema é que a maioria das empresas não tem catalogada todo o arsenal de tecnologia usado para gerenciar o tráfego em aplicações desenvolvidas internamente e compradas de terceiros.
Apenas para se ter uma ideia do problema de tentar resolver uma exposição ao risco sem os ativos catalogados, considere a tarefa de um CTO em uma empresa que usa 50 mil servidores. Ele vê um relatório sobre o bug Heartbleed e entende que é importante aplicar as atualizações, mas como saber por onde começar se as tecnologias implantadas não foram devidamente catalogadas? Onde elas estão instaladas? Como são usadas?
Esse bug é um desafio imenso para instituições financeiras, mas os sites de bancos, é bom lembrar, têm uma grande variedade de tarefas. Um servidor usado para um portal de clientes não necessariamente coleta dados sensíveis, diferente daqueles onde rodam aplicações bancárias que captam dados como usuário e senha para acessar contas. Uma catalogação detalhando qual código aberto foi usado para desenvolver cada aplicação e onde ela foi instalada poderia dar ao time de TI as ferramentas necessárias para priorizar o processo de “limpeza”.