Últimas notícias

Fique informado
Open-Source: verdades inconvenientes. Por David Ben Svaiter

Open-Source: verdades inconvenientes. Por David Ben Svaiter

1 de novembro de 2021

Início aqui mais um artigo polêmico, para colocar na mesa algumas “verdades inconvenientes” a respeito dos sistemas-de-código-aberto (Open-Source).

Escrito pelo Professor David Ben Svaiter

Professor David Ben Svaiter, Criptólogo e Desenvolvedor

Digo que o artigo é polêmico pois remete a uma outra briga de décadas: Microsoft Windows versus Linux, um dos mais famosos “open-source” do mundo (sim, Linux nasceu e é “open-source”), uma discussão constantemente acalorada e que possui defensores ferrenhos em ambos os lados.

Mas não irei caminhar por essa trilha. Gosto do Windows assim como gosto do Linux. Ambos possuem qualidades e problemas que não quero nesse momento debater. Vou para uma análise mais ampla sobre o tema “código-aberto”.

Uma pequena introdução histórica

O conceito “open-source” nasceu nos EUA, quando um punhado de influenciadores da comunidade de programação (capitaneados por Eric Raymond) rebelou-se contra o poder econômico das “big-techs”, desejosos de criar um sistema de criação e distribuição de software que fosse universalizado para países de baixa renda, permitindo sua inclusão no mundo informatizado. Basicamente, os objetivos do “open-source” eram:

– Promover a criação de código-de-programação (sistemas operacionais, utilitários, ferramentas etc.) gratuitamente.

– Promover a distribuição de tais códigos em formato “aberto” (o código-fonte seria disponibilizado) permitindo variações e personalizações, sem vendas ou cobrança referente aos “direitos autorais” – apesar de exigir que tais direitos fossem respeitados para sua utilização.

– Utilizar sistemas de distribuição igualmente abertos e de acesso público irrestrito.

– Promover a participação de pessoas capacitadas na criação e manutenção de tais códigos, em um esquema “colaborativo” (sem remuneração de qualquer espécie).

Estimular tal participação em busca da excelência de código, apostando que, por ser “aberto” a todos, o nível de inspeção e análise contribuiria decisivamente para a detecção de problemas e melhoria do código através de contribuições e otimizações.

Se tiver interesse em uma descrição mais precisa e completa, sugiro dar uma olhada nessa reportagem do CANALTECH (que parabenizo pela pesquisa e autoria!).

Bacana a filosofia do negócio! Durante muitos anos, os “open-source” foram sendo conhecidos e praticados apenas dentro das mais antenadas e inovadoras comunidades de programação, até que Linus Torvalds lançou um sistema operacional digno de competir com o império da Microsoft nesse ambiente (MS-Windows), chamado de LINUX – um acrônimo formado pelo seu primeiro nome e o nome do sistema operacional que serviu de base (UNIX).

O sistema operacional teve ampla repercussão em todo o mundo e carregou assim o conceito que até então era inimaginável para o cidadão-médio: como alguém me fornece um sistema operacional completamente de graça e quem o mantém?

Décadas se passaram e muito programadores cresceram sob essa filosofia, acreditando que para obtermos um mundo melhor e mais justo, os paradigmas de criação, direitos e comercialização de “software” deveria seguir a linha “open-source”.

Faz sentido? Na teoria sim, mas na prática…

Não foi fornecido texto alternativo para esta imagem

Quem lida com tecnologia sempre brinca que, para cada problema que a tecnologia resolve, criam-se um ou mais problemas que não existiriam sem ela.

A comunidade “open-source” teve um crescimento exponencial a partir de 2010 e milhares de softwares foram lançados seguindo esse conceito. Algumas empresas, aproveitando-se dessa “filosofia” que cativava os mais jovens, criavam seus produtos disponibilizando o código fonte em sistemas abertos, mas cobertos por licenças específicas onde os direitos autoral e comercial são restritos, ganhando em diversas frentes:

Notoriedade dentro da comunidade técnica

Afinal, esse conceito representa uma empresa moderna, justa, imparcial e que respeita o planeta e as pessoas mais pobres – muitos caem nessa, acredite!

Baixíssimo custo de programação e manutenção de código

São poucos os colaboradores formais (funcionários da Empresa) que comandam um time de centenas ou milhares de profissionais a custo-zero: os colaboradores em sentido estrito.

Custo inexistente ou baixíssimo para PDCA e Melhoria-Continua

Já que, conforme acima apontado, tais Colaboradores detectam problemas e sugerem melhorias e “fixes”, muitas vezes até codificando o que sugerem.

Mas, como o título desse parágrafo sugere, essa nova “tecnologia” (ou filosofia como alguns preferem) trouxa à tona varios problemas que são hoje sumariamente negligenciados pelos seus apoiadores e pelos decisores que, sem o devido expertise para contra-argumentar, acabam por comprar o conceito de forma cega.

NÃO EXISTE ALMOÇO GRÁTIS!

https://www.linkedin.com/embeds/publishingEmbed.html?articleId=7581575778904727790

Milton Friedman popularizou essa frase em relação à Governos, mas em nosso século podemos apliar o conceito para outras frentes; como as redes-sociais gratuitas “onde você e seus dados são a mercadoria”.

Seguindo a mesma lógica: faz sentido uma empresa criar algo gratuitamente, sem nenhuma receita que a permita prosseguir e sobreviver?

E aí entra uma das grandes confusões que o pessoal trouxe do passado: “open-source” não é (necessariamente) sinônimo de “código-gratuito”!

Muitas empresas hoje disponibilizam seus códigos (ou parte destes) em ambiente “aberto”, mas isso não significa que podemos pegá-lo e usá-lo sem pagar pela “licença de uso”. São programas comerciais SIM, mas que são mantidos e evoluem sob a ótica de um “open-source” com as características que aponto acima – e nada mais que isso.

Além disso, muitas outras empresas de “código-fechado” (restrito, não-público, exclusivo) utilizam-se de componentes de “open-source” pelas mesmas razões mais acima apontadas: economia (principalmente), eficiência e eficácia.

Em outras palavras, uma filosofia criada para popularizar e democratizar tecnologia, mas que hoje é usada para gerar menos custo (e mais lucro) em muitos casos.

Existem ainda os “open-source” totalmente gratuitos? Sim, claro! Mas estes, em sua ampla maioria, são mantidos por “comunidades” de profissionais, sem um escopo formal definido (“empresa”) e por conseguinte, sem as responsabilidades e deveres que toda empresa-cliente deve ter em garantia ao adquirir um software (veremos isso depois).

Antes de prosseguir quero deixar claro que não sou contra nada do que acima foi escrito. O objetivo desse artigo não é desmerecer o “open-source” ou aqueles que os apoiam – longe disso – mas chamar a atenção para o aspecto de SEGURANÇA que, diferente do que muitos pensam, não é superior aos sistemas de código restrito/privado.

Portanto, veremos como o ecossistema “open-source” traz alguns problemas graves e isso não é meramente uma opinião, mas uma conclusão pautada em estatísticas e fatos.

Destes, vou explorar apenas tres dos principais problemas:

  1. SABOTAGEM
  2. VULNERABILIDADE & QUALIDADE
  3. RESPONSABILIDADE COMERCIAL E LEGAL

A imagem acima foi capturada do artigo de Paul Sawers, de setembro de 2021 e reflete algo que toda a comunidade de Segurança da Informação já sabe – e os “de fora” vêm tomando ciência pelas notícias quase que diárias: os ataques digitais (e prejuízos com eles) só aumentam, semana após semana, mês a mês…

E onde os “open-source” entram nisso? Em quase todos os “next-gen softwares” meu amigo… afinal, como citei mais acima, não há empresa que hoje deixe de utilizá-los por marketing ou economia, considerando ainda que existem códigos criados especificamente para promover ataques usando a gratuidade e o conceito “aberto” como véus de legitimidade. É o conceito “open-source” usado como vetor de ataque.

Não podemos esquecer também que, justamente por serem alterados colaborativamente, existem “programas” (no sentido de metodologia tática) bastante eficazes que forçam os criadores a vulnerabilizar códigos, através de falsos-alertas ou ainda falsas-checagens. Em ambos os casos são criados perfis (que podem chegar às centenas) que notificam os criadores sobre problemas de fato inexistentes, sugerindo modificações que (sutilmente) irão vulnerabilizar o código. No segundo caso, o mesmo processo é usado para validar tais modificações ou ainda, validar outras que podem ter sido legitimamente criadas, mas que possuem “0-Day Vulnerabilities” (vulnerabilidades desconhecidas pelos criadores).

A NSA fez aplo uso de tais táticas e hoje, com o advento de IA e robôs de interação, essa tarefa é muito mais simples e barata e pode envolver milhares de perfis falsos.

Junte o que estou dizendo e entenderá alguns motivos do aumento de 650% em 12 meses no número de ocorrências de ataques/vulnerabilidades através de códigos-abertos.

E convenhamos: aumento de 650% em um ano é algo muito grave e que deve ser levado muito a sério!

Mas, partindo do princípio que o “open-source” é de fato legítimo e lícito em todos os sentidos, como podem representar risco ou oportunidade para terem esse aumento de volume em ataques?

Sabotagem

Existem vários controles para se evitar que um código “open-source” seja sabotado e basta conhecer o processo para perceber isso claramente. Entretanto, o que poucos conseguem ver é que a sabotagem é possível em 3 situações:

Acesso indevido por pessoa autorizada.

Em outras palavras, o “inimigo interno” que tem autorização de modificação de código e altera determinadas linhas sem o conhecimento dos revisores. Tais pessoas são muitas vezes cooptadas por quantias generosas de organizações com interesses escusos (USD 1 milhão te parece pouco?) ou mesmo por órgãos de Estado (veremos isso adiante).

Alguém se lembra do caso da Tesla? E esse é apenas um deles, e um dos pouquíssimos onde o cooptado denunciou o fato.

Mas o que tem “open-source” com isso? Acredite: TUDO. Grandes empresas sofrem o mesmo problema através de eventuais códigos que utilizam: SolarWinds Explained and Why it was So Difficult to Detect.

Lembremos também que, justamente pelo apelo de “gratuidade”, vários são os alvos dentre a comunidade “open-source” para disseminação de malware e ransomware – afinal, são os vetores ideais para esse tipo de ação.

Será por isso que vemos um aumento exponencial em ataques digitais à empresas de todos os portes?

Acesso indevido por grupos não autorizados.

Nesse caso, o código é literalmente invadido e modificado, assim como todos os controles que afiançam sua legitimidade. Coloco como “grupos” pois é um trabalho em geral promovido por grupos especializados, tanto privados como os “de Estado”.

Atores Privados: quando pensamos em “hackers” imaginamos aqueles adolescentes no fundo de seus quartos durante a madrugada ou ainda, um pequeno e seleto grupo de “rebeldes digitais” com alguma “causa”. Apesar destes ainda existirem, grande parte dos ataques digitais são construídos e executados por empresas (ou mesmo grupo de empresas) com grandes orçamentos e alta governança corporativa, na maioria das vezes de forma legal.

Antes de abrir um olhar de incredulidade, lembre-se que mais de 98% dos códigos utilizados em ataques digitais são os mesmos utilizados em qualquer outro software e pelo menos 1,5% do restante é utilizado por equipes de RED TEAM e BLUE TEAM – equipes especializadas em prevenir ataques digitais através do conhecimento especializado para ataque e defesa, respectivamente. Lembro ainda que o ambiente acadêmico sobre esses temas é farto e amplo.

Junte as peças e verá, portanto, que um ator-central pode sim contratar diversas empresas e profissionais com o devido expertise, onde cada uma delas será responsável por uma “peça” de um grande quebra-cabeça que só este ator terá conhecimento – e normalmente a condição de execução do todo.

Atores de Estado: é fato notório que Governos promovem grupos especializados de ataques digitais sob a ótica de “cyberwar”. Tais ataques são mais conhecidos quando atingem estruturas de comunicação, mas ocorrem em todo o ecossistema digital e os ambientes “open-source” não estão a salvo disso – pelo contrário, estão muito mais expostos do que se imagina.

Edward Snowden já citava isso em 2013, apontando que dentre os vários programas de espionagem da NSA, havia aqueles que vulnerabilizavam códigos-fonte em sistemas “open-source”; as vezes de maneira secreta, as vezes cobertos por leis específicas que dão à NSA autorização para tal.

E não pense que isso é um privilégio norte-americano – não é! Vários são os Governos que promovem as mesmas atividades e miram os mesmos alvos em outros países.

Coloque agora o que acabei de falar nesses parágrafos sob a perspectiva de espionagem industrial, comercial ou mesmo militar ou estratégica e verá porque o ambiente de ataques digitais é amplamente buscado e financiado.

Vulnerabilidade & Qualidade

Inicialmente faz sentido que uma ampla comunidade de pessoas capacitadas seja mais eficaz em criar códigos mais seguros e de melhor qualidade que um time de poucas dezenas de profissionais.

Mas na prática nem sempre é o que vemos.

Não podemos esquecer 2 aspectos envolvidos:

Esquema Colaborativo

Como cobrar de “verdadeiros colaboradores” (aquele que colabora de boa fé e sem remuneração alguma) a responsabilidade e métricas para que se desenvolva código de alta qualidade?

Alguns dirão que seu código será revisado por pares e os problemas detectados nessa etapa. Mas será que os “revisores” têm a devida expertise para isso? Isso nos leva ao ponto seguinte.

Mas antes de entrar nele, sugiro reler o que cito em “Sabotagem”, para entender como um esquema colaborativo pode ser minado para atender a interesses específicos.

Expertise

Como tudo na vida, nem sempre “um time” de profissionais talentosos é garantia de qualidade e performance. Agora imagine um time absolutamente eclético e trabalhando junto numa área que, comumente, exige diferentes “experts” de diferentes áreas. Vulnerabilidades nem sempre estão relacionadas diretamente ao código (qualidade) mas na negligência aos diversos tipos de ataques laterais; códigos que não preveem determinadas condições que podem ser aproveitadas para se elencar um ataque vindo de outro lugar e de outra forma.

Recentemente isso foi visto no ataque à SolarWinds , ataque do tipo “escalação” (pense em alpinismo mesmo) vindo através de um componente literalmente terceirizado: o componente era utilizado num código que, por sua vez, era um componente de uma biblioteca de código de outro terceirizado e utilizada no SolarWinds.

Acha que isso é um caso isolado? Sinto dizer que está enganado.

Tanto não é um caso isolado que vemos uma entidade criada justamente para mitigar tais ocorrências: a Open-Source Security Foundation – OpenSSF.

Mas, como aponto no tópico “Sabotagem” mais acima, monitorar e garantir a qualidade e segurança de códigos “open-source” é uma tarefa ingrata e extremamente difícil.

Lembro que há centenas de exemplos que poderiam ser aqui colocados, passando pelas maiores empresas do mundo (mesmo aquelas especializadas em segurança) até em ambientes de “cloud”, como Microsoft Azure Cosmos e Lunix VM, softwares de alto padrão e utilizados por inúmeros Governos e grandes empresas.

Pesquise nos últimos cinco anos qual o porte e poder-econômico das empresas atacadas e busque saber qual o tamanho do orçamento de defesa cibernética que elas mantinham.

Ou você acredita que tais empresas foram atacadas por não possuírem capacidade técnica nem orçamento para evitá-los.

Quando pensamos em empresas desenvolvedoras de software a primeira coisa que nos vem à cabeça é: “ora, porque vou pagar por um software se posso correr atrás de algo gratuito?”. Esse pensamento é por demais simplório e nem sempre verdadeiro, afinal, já vimos que “open-source” não é necessariamente sinônimo de gratuidade.

Mas a grande questão aqui é:

Em casos de ataques ou interrupções do negócio causados direta ou indiretamente pela ferramenta, a quem recorrer?

Minha empresa tem por hábito promover melhoria-contínua semanalmente, alocando tempo e recursos em P&D (Pesquisa-e-Desenvolvimento) e suporte adequado – comprove em nosso histórico de “releases”. E quando falo de “suporte” falo em responder o mais rapidamente possível às demandas que surgem, trazendo tranquilidade aos nossos usuários que, inevitavelmente, irão reconhecer nosso esforço e comprometimento e nos garantir a fidelização que buscamos com isso.

Para nós, é uma questão-chave suportar nossos clientes com rapidez, qualidade, eficiência e eficácia.

Obviamente que isso nos traz custos diversos que são, naturalmente, financiados a longo prazo pelo preço da licença-de-uso do produto.

Isso nos leva a uma questão fundamental atrelada ao serviço: responsabilidade comercial e legal, conforme previsto pelas diversas leis de defesa do consumidor. Como empresa produtora de software e prestadora de serviços correlatos (consultoria, manutenção, etc) estamos sob a legislação fiscal e de proteção ao consumidor – um fato que traz garantia e segurança aos nossos usuários.

Mas e quanto aos “open-source” em sua maioria? Estão sob a mesma responsabilidade? Na ampla maioria das vezes, não.

Conforme mostrado no início desse artigo, o LICENSE AGREEMENT praticado na maior parte do ecosistema “open-source” garante apenas os DIREITOS AUTORAIS, não existindo tacitamente nenhuma responsabilidade técnica, legal ou comercial.

E isso sem contar aqueles que, sendo pagos e tendo ALGUMA responsabilidade legal (em geral leis de seus países de origem), acabam por levar dias ou semanas para mitigar ou eliminar problemas, já que o processo de modificação-de-código segue uma hierarquia de procedimentos e revisões que é intrinsicamente lenta e dividida entre diversas pessoas e etapas, objetivando proteger o código contra modificações maliciosas ou danosas – entretanto com baixa eficácia como aponto lá em cima no tópico “Sabotagem”.

O que fazer então? Abandonar os “open-source” como solução?

Não; mas praticar a análise holística antes de adotá-los é FUNDAMENTAL!

Recomendo ao leitor sempre que for escolher um software (ou um componente) reflita sobre o que aponto no artigo e pese os custos e os benefícios de cada uma de suas escolhas.

A economia proposta pelo “open-source” é relevante, claro. Mas não deve ser a palavra final quando a utilização da ferramenta pode oferecer riscos de ataques, vulnerabilidades ou continuidade-do-negócio.

Vários outros fatores devem ser considerados para que não caiamos numa falsa “vantagem” imediata e que pode se tornar uma dor-de-cabeça imensa em algum momento.

Lembre-se: as estatísticas de ataques demonstram o que acabei de falar! Grandes empresas sendo alvo de ataques ou falhas que geram milhões em prejuízos diversos, muitas vezes ocasionados pela “economia estúpida” que um software gratuito ou muito barato promete – seja ele “open-source” ou não.

Finalizo com o mote de um novo artigo em breve:

Então recomendo adquirir apenas softwares caríssimos e de empresas de grande porte? Não, de forma nenhuma!

Pensar assim é estar com a cabeça no século XX, descartando todo um ecossistema de inovação e “startups” que se acelerou no século XXI e que apresentam soluções altamente eficientes e eficazes com um custo adequado ao seu tamanho!

No Brasil (diferente de paises como Israel, USA, e váris outros) ainda existe um grande entrave às soluções inovadoras de empresas “startups” apenas pelo fato da maioria dos gestores e equipes estarem presos à paradigmas antiquados e injustificados como “marca” ou “tamanho da empresa” fornecedora – condições estas que não as eximem de serem atacadas ou vulnerabilizadas conforme as estatísticas demonstram.

Finalizo esperando ter dado uma luz a um assunto-tabu que poucas pessoas têm a coragem de encarar – uma verdade inconveniente.

Leia outros artigos do professor em obake.

David Ben Svaiter

  • Criptólogo
  • Desenvolvedor de Soluções de Criptografia
  • CTO da NAWKA (startup de inovação em criptografia)
  • CEO da OASYS INFORMATICA
  • Professor e Orientador convidado da Marinha do Brasil para curso de Criptologia na Pós-Graduação
  • Consultor especializado em Criptografia/S.I

Fonte: LinkedInAs imagens foram substituídas por imagens contratadas pelo Crypto ID

Cuidado, você pode ser sequestrado! Por David B. Svaiter

O Avestruz e a Lei de Gérson

Google grava sua voz sem você saber

IoT: porque a Internet das Coisas ainda não está pronta?

Privacidade? Pra quê?

Self-Encrypted Drives | Sensação de Segurança

Você quer acompanhar nosso conteúdo? Então siga nossa página no LinkedIn!