Heartbleed hace reaccionar a los gigantes de la tecnología

La Linux Foundation lidera una iniciativa para dar apoyo económico a “proyectos Open Source críticos en la infraestructura global de la información”, todo a causa del desastre mayúsculo que supuso Heartbleed. Como miembros fundadores, Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace y VMware.

El programa impulsado consta de financiación de varios millones de dólares para los próximos años que serán inyectados por las compañías citadas y otras y administrados por la Linux Foundation “y un grupo directivo integrado por los partidarios del proyecto, así como por los principales desarrolladores de código abierto y otras partes interesadas de la industria”.

En esencia, se trata de amparar económicamente a proyectos clave para la seguridad como el mismo OpenSSL, protagonista del gran agujero de Heartbleed y primero en recibir fondos ahora. Y es que OpenSSL es todo un ejemplo en este sentido: en los últimos años sus ingresos por donaciones fueron de 2.000 dólares.

En efecto, que un software como OpenSSL sea mantenido y desarrollado por voluntarios de manera precaria, es un sinsentido. O, en otras palabras -las de Eben Moglen, profesor de la Escuela de Leyes de Columbia y director fundador del Software Freedom Law Center-, “el mantenimiento de la salud de los proyectos comunitarios que producen software crítico para la seguridad y protección del comercio por Internet es del interés de todos.”

Opinión / rectificación:

Cuando a razón de LibreSSL decía que “organismos internacionales deberían controlar y asegurar económicamente desarrollos como OpenSSL”, erraba con la definición. Esta iniciativa de la Linux Foundation es loable y según cuentan, no habrá intromisión en la dirección de los proyectos auspiciados. Pero tiene fecha de caducidad. ¿Qué pasará después?

Las grandes empresas de ingentes beneficios deberían financiar los, como ponía más arriba, “proyectos Open Source críticos en la infraestructura global de la información”. Sin embargo, no deberían hacerlo porque quieren, porque más adelante pueden “no querer”, sino porque les obliga el estado, que a su vez debería ser el encargado de gestionarlo y auditarlo todo, software incluido. Y como todavía no hay un único estado gobernando el planeta, debería ser un organismo internacional competente el que realizase la tarea.

[Imagen: Shutterstock]

Empresas Heartbleed Internet Linux Foundation Open Source OpenSSL Seguridad

toomanysecrets
La noticia en sí es estupenda, pero lo que no llego a entender es porqué, habiendo un fork como hay (libreSSL), que ya tiene un montón de depuración hecha, así como eliminadas unos miles de líneas de código, se ponen a meter dinero a un “grupo” que ya disponía de algún que otro parche sobre vulnerabilidades pasadas, y otras que todavía no han salido. Salvo que se me escape algún otro dato (dejando de lado la publicidad que les dá este tema, especialmente en la comunidad linuxera), no entiendo porqué razón no invierten ese dinero en el proyecto LibreSSL, o lo reparten con él o, sencillamente con ese dinero, no inician la creación de un fork partiendo de cero :-/
- Otto Swanstaiger
  ¿Tendrá que ver que LibreSSL fue creado por gente del proyecto OpenBSD?
  A Linus no le agradan los muchachos de OpenBSD, según él son una panda de monos pajeros que sólo se preocupan por la seguridad.
  Como sea, mi voto de confianza va con LibreSSL. Conozco el trabajo de la gente involucrada y estoy seguro que saben lo que hacen. Son buenos hackers que saben mucho de criptología; mientras que el equipo de OpenSSL está compuesto por buenos criptólogos que poco saben de hacking.
  - Mirage
    tambien tendra que ver que los chicos de openBSD han quitado mucho del codigo que hace a libreSSL compatible(segun el tipo los de openBSD quitaron los certificados FLIPS que son dependencia critica en muchas distribuciones liux como opensuse) con otra cosa que no sea un BSD por ejemplo hace poco en los foros de opensuse en G+ un mantendor de openSSL dijo que habian los de openBSD quitado varios certificados y protocolos que hacen a libreSSL incmpatible con el software actual. en otras palabras libreSSL es un proyecto crado a la medida de openBSD.
    de todas maneras me parece mas razonable en ligar de cambiar todo el codigo y adaptarlo a u fork que aun esta en estado alfa, que se implementen algunos de los cambios que iso openBSD y ya.
    - Otto Swanstaiger
      La idea es quitar el código que hace a OpenSSL portable y una vez que tengan una base sólida comenzar a recibir parches para portarlo a otros sistemas. Se hace así porque el enfoque de portabilidad de OpenSSL es muy malo, oscurece muchos problemas (incluido el bug hearbleed), y es muy difícil de auditar.
      Todos los sub-proyectos de OpenBSD (OpenSSH, OpenSMTPD, OpenNTPD, OpenBGPD, OpenIKE, Inetd y mandoc) son portables, no veo por qué LibreSSL va a ser la excepción.
      .
      - Mirage
        no digo que no lo vaya a ser. digo que por ahora no lo es y dudo mucho que la mayoria de las compañias cambien de la noche a la mañana ese componente. se limitaran a implementar los cambios que puedan y listo
- Marito
  El lider de OpenBSD/LibreSSL es autor de frases como “Linux is for losers” y Linus Torvalds tampoco se queda corto con las respuestas (Otto Swanstaiger lo menciona). Son simples antagonismos dentro del mundo del software libre. No creo que no haya pasado por la cabeza de RedHat y tantas otras hacer su propio fork de openSSL, algun motivo habrán tenido para continuar este proyecto.
gnamboo
Podemos descartar desde ya que los estados o las instituciones públicas internacionales hagan algo al respecto, cuando no son capaces, no ya de cortar de raíz, sino ni siquiera de minimizar el hambre en el mundo, pese a que se desechan millones de toneladas de comida “para estabilizar los precios” o se mantienen en stock para especular con ellos o se dedican a la producción de biocombustibles.
No, amigos, esto no sucederá.
No obstante, la Linux Fundation ha dado un paso de gigante con esta iniciativa. Con ella puede convertirse en un actor decisivo y relevante en el impulso y expansión de los proyectos de software open source en el mundo. Sí, por ahora se trata de un programa con fecha de caducidad. Pero es muy probable que si los beneficios de este programa empiezan a ser palpables a corto o medio plazo, las empresas, que no son tontas, se replanteen seguir contribuyendo. Y quién sabe, se produzca un efecto bola de nieve…
A mí me parece un punto de inflexión en la historia del Open Source.
- Marcos Mora
  En efecto, fíjate que en mi pais, (Venezuela) la corrupción Estatal deja podrir la comida importada (miles de toneladas) en los puertos, sabiendo que la producción nacional de alimentos no alcanza, y tenemos escasez de cientos de productos de toda clase SOLO por la intervención Estatal miope.
  Se desechan millones de toneladas de comida “para estabilizar los precios” me imagino que te refieres a la política Estatal agrícola de la unión europea. La cual es un completo sinsentido, porque los subsidios (intervención Estatal) masivos llenan el mercado internacional, y hace que los paises que solo tienen su tierra cultivable para ofrecer al mundo, no puedan competir ni obtener ingresos necesarios para mejorar su nivel de vida.
  Resultado: hambre en un lado, obesidad y desperdicio en otro.
DELTOYA
¿Dejar la responsabilidad de la seguridad en las comunicaciones a cargo de los gobiernos// organismos internacionales?, mucho mejor ¡dónde va a parar!
- MetalByte
  Ok, los gobiernos no son de fiar… ¿y las empresas sí? La cuestión es que este tipo de proyectos críticos para la seguridad necesitan financiación para que su desarrollo sea sólido, y necesitan auditorias que certifiquen esa solidez, y eso es mucho dinero.
  En un mundo ideal todos estos proyectos estarían respaldados por una comunidad fuerte e independiente, pero en el que nos ha tocado…
  Otra solución sería que organismos internacionales obligasen a las grandes empresas a financiar estos proyectos bajo gestión de ONGs tipo EFF, pero tampoco parece que vaya a suceder..
  - gnamboo
    Descartada la opción ideal, al menos podemos darnos con un canto en los dientes por el hecho de que sea la Linux Fundation la patrocinadora de esta iniciativa. Pero, claro… ¿no está la Linux Fundation cada vez más en manos de las multinacionales? Todavía peor: si la mayor parte del open source, por lo menos las aplicaciones más críticas, va a depender del dinero de las multinacionales para su desarrollo… ¿no quedaría prostituido el concepto mismo de open source?
    Una cosa está clara: una gran parte de las comunidades open source no poseen recursos propios para sacar adelante proyectos con estándares de calidad elevados. O son las multinacionales, o hay una toma de conciencia masiva en favor del software comunitario.
    Y, por ahora, esa hipotética toma de conciencia se ve lejana… muuuy lejana.
    - staff
      El Open Source esta prostituido desde el momento en que que grupos pro empresariales tomaron el termino como estandarte.
      Lo que empezó como una loable intención de evitar la ambigüedad que el idioma ingles le da a Free (Gratis y libre) fue desmembrado y mutilado hasta dejarlo en solo un modelo de desarrollo.
      Al grado en que ahora por todos los foros te topas gente que dicen apoyar tal o cual programa solo por que en el nombre incluyen Open y no Free, bajo la excusa de que “apoyan esa filosofia”, y ni siquiera se fijan que algunos de esos proyectos tienen licencias como la GPL, que representa toda la ideología del software libre.
    - Mirage
      el opensourse en linux esta protituido desde ahce mas de una decada. o es que no son acaso empresas y multinacionales como intel y sansung ( redhat) las que aportan el 88% del codigo del mero kernel solo para dar un ejemplo. no hablemos ahora de Gnome o de KDE (que para el proyecto Nepomuk recibió apoyo economico de la union europea y actualmente google es uno de sus mas grandes contribullentes) solo dando ejemplos de como las piezas mas “claves” de linux financiadas por multinacionales en maor medida.
  - DELTOYA
    Vivas donde vivas Gobierno= Barclays, AXA, Deutsche Bank, etc (incluso en países donde mandan los cárteles hay detrás empresas que puedes encontrar en Gran Vía, Paseo de Gracia o Tetuán).
    Dejar algo en manos del Gobierno es dejarlo en manos de empresas. Por eso es preferible que siga siendo la Comunidad la que soporte el peso del software libre.
    - MetalByte
      Eso suena muy bonito, pero es un ‘utopic unicorn’ ;)
      - DELTOYA
        No te digo que no, pero la cuestión es hasta qué punto prostituir lo que hoy tenemos con tal de extender su uso. ¿Que los proyectos necesitan financiación? pues como todo.
        En mi caso (hoy por hoy) estoy contento con Gnu/Linux y (hoy por hoy) no me merece la pena arriesgarme a perder ciertas “garantías” por ver Gnu/Linux en un catálogo del Media Markt. ¿Mentalidad cortoplacista? puede ser, pero como compatriota que eres ya sabes lo que mejoran las cosas cuando al gobierno le da por meter las narices en el algo.
      - MetalByte
        El problema es que mucho de lo que hoy tenemos ya está prostituido, y si lo que no lo está (o no sabemos que lo está) y además es de verdad relevante, falla, como ha ocurrido con OpenSSL… apaga y vámonos.
        De todas formas, cuando hablo de organizaciones gubernamentales no me refiero a políticos, sino a expertos en la materia. Pero entonces me dirás que esos expertos estarían sometidos a intención política y es la pescadilla que se muerde la cola.
      - DELTOYA
        Estoy de acuerdo, lo deseable sería dejarlo en manos de los tecnócratas ¡pero eso también es muy unicorn! (teniendo en cuenta el nepotismo reinante).
        lamentablemente es un axioma: proyecto rentable—>buitres
roader
Bueno , ahora ya sabemos por que no aplicaban parches …
Marcos Mora
El “papá” Estado “debe hacer”, “debe protegernos”. Opino lo contrario, cuando papá estado se mete, exige sumisión, genera ineficiencia, clientelismo, corrupción, etc. Ejemplos sobran, sin ir muy lejos la NSA.
Todo eso es menos probable que ocurra si solo la gente no-gubernamental hace su trabajo. La solución en este caso particular es aplicar con mayor conciencia el modelo de desarrollo libre, el cual permite que las personas interesadas (fuera de los desarrolladores propios) lean el código, escriban código, y hagan el commit.
Gúgolplex
La solución sería que trabajaran de gratis.
Ds23yTube
Quien sabe, de errores así, a lo mejor GNU/Linux despega al filo del triunfo aún más. No todo son malas noticias.
Jristz
Y com todabia no hay un unico organismo internacional competente que realize u obligue a las empresas a hacer eso, ahí te vez
Ken Torrealba
Así lo finasen los gobiernos, o lo auditen grandes compañías.
CUALQUIER PERSONA, con el conocimiento adecuado, PUEDE re-auditar el código y manifestar sus inquietudes.
Andrés Correa Casablanca
Respondiendo a @toomanysecrets:disqus , las confrontaciones entre el proyecto OpenBSD y los proyectos asociados más fuertemente a Linux es una causa probable, pero hay una mucho más importante.
En su impaciencia, los desarrolladores de libreSSL se han cargado una cantidad tal de código que se ha roto la compatibilidad con Linux, Mac OS X, Windows y otros sistemas aun menos conocidos (Solaris, QNX, Minix, etc.). Sus motivos son claros: necesitaban ir rápidos, y mantener compatibilidad con un gran número de plataformas a la vez que se mejora la arquitectura es harto difícil, lento y caro. Si quieren asegurar que los sistemas BSD son los más seguros del mundo no pueden permitirse el lujo de depender de otros.
Estas grandes compañías que ponen dinero para mejorar OpenSSL no se pueden permitir romper esa compatibilidad, pues operan simultáneamente con sistemas de todo tipo (como mínimo Linux, MacOS y Windows). Además, tampoco les conviene crear una nueva organización con un nuevo fork de OpenSSL, pues eso supondría que de tener 2 variantes pasaríamos a tener 3 (por orgullo o por inercia, OpenSSL seguiría existiendo durante bastante tiempo).
——————-
Volviendo al artículo… no estoy demasiado de acuerdo con las opiniones expresadas al final. Los estados no deberían obligar a financiar mantener ciertos proyectos, al menos no directamente.
Sería lógico que, igual que hay ciertas regulaciones de seguridad en la construcción de edificios, maquinaria, vehículos y cualquier otra cosa que pueda tener grandes riesgos asociados, debería haberlas para grandes infraestructuras informáticas y para cierto tipo de software orientado a la manipulación y transmisión de información valiosa.
Aun así, regular el desarrollo de software es un asunto peliagudo por motivos de mucho peso:
1 – los legisladores son patéticamente lentos y el desarrollo tecnológico es muy rápido.
2 – hay que dejar margen a la creatividad y la innovación… a la vez que se tiene que fomentar la interoperabilidad.
Qué “mínimos” se podrían exigir a las empresas? Se me ocurren algunos que podrían llegar a ser tolerables (aunque se quejarían).
1 – Mantener sus plataformas actualizadas (en lo tocante a seguridad) (puede parecer una chorrada, pero ahora no es una obligación). Se podrían estipular plazos máximos para actualizar en función de la gravedad de los problemas de seguridad resueltos (y también en función del grado de exposición de los servidores, no es lo mismo un servidor directamente accesible desde internet que uno accesible solo a través de una red local). Hay varios baremos de clasificación de peligrosidad, sería cuestión de que se escogiera uno (o se elaborara uno nuevo) y se trabajara con él para establecer esos plazos.
2 – Realizar auditorías de seguridad de forma periódica, con intervalos no más altos de un año. El periodo podría depender del tamaño/capital de la empresa, o del número de servidores levantados, o del número de clientes/usuarios, o de cualquier otro parámetro que pueda co-relacionarse positivamente con el riesgo de sufrir un ataque. Ya sé que actualmente se hacen auditorías, pero no acostumbran a ser frecuentes… y algo peor: las recomendaciones de los auditores no acostumbran a ser vinculantes. Lo peor que les puede suceder es que pierdan alguna certificación ISO (que sirve para atraer a clientes), pero nada de sanciones económicas o bloqueo de servicio (¿por qué se puede vetar la entrada en un edificio a punto de derrumbarse pero no hay ningún juez que decrete el cierre de un servicio web por inseguro?)
3 – Como decía: Las recomendaciones de las auditorías deberían ser vinculantes, con plazos máximos para cumplirlas, y con sanciones económicas o de hasta cierre del servicio en caso de incumplimiento.
4 – (Este punto está especialmente enfocado a macro corporaciones) Mantener un “inventario priorizado” de los componentes de software críticos para la seguridad de la infraestructura tecnológica, y en función de ese inventario y del volumen de la empresa, obligarla a destinar una cantidad relativamente pequeña de recursos al mantenimiento de esos componentes.
5 – Las empresas que desarrollaran software comercial (generalmente privativo, pero en esencia, software por el que obtienen un lucro), deberían estar obligadas a que su software cumpliera unos mínimos. Tests unitarios con cobertura por encima del 70 u 80%, chequeos de fugas de memoria, chequeos de inyección de código… y esos mínimos deberían estar establecidos por el gobierno. Cumplir ISOs está muy bien, pero no cumplirlas no tiene casi consecuencias. No cumplir las exigencias del gobierno sí acostumbra a tener consecuencias.
La dificultad de los puntos que planteo está en establecer cuales son los límites y coeficientes que deberían aplicarse, para no joder a las pequeñas empresas pero a la vez permitir que haya un mínimo de seguridad.
Qué mínimos deberían pedírsele a los gobiernos?
1 – El punto 4 anterior, podemos entender a casi cualquier gobierno como una mega corporación.
2 – El punto anterior no solo serviría para asegurar las infraestructuras gubernamentales, sino también para crear una especie de “auditoría cruzada” entre empresas y gobierno, asegurando un mínimo equilibrio de poder (recordemos que estamos hablando de componentes de seguridad que podrían ser modificados con intenciones de dudosa legitimidad).
3 – Preocuparse de crear algún boletín oficial de seguridad informática. Está muy bien que los haya privados, pero debería haber una referencia oficial para poder tener una mínima seguridad jurídica en lo tocante a las obligaciones empresariales respecto a la seguridad de sus infraestructuras informáticas. (Conocer la LOPD ya no sería suficiente).

Heartbleed hace reaccionar a los gigantes de la tecnología

Lo último

Suscríbete gratis a MuyLinux

Gracias por suscribirte a MuyLinux.