¿Deben las empresas usar software libre? Esa ya no es la pregunta, sino más bien: ¿Bajo qué criterios se debe usar el software libre? Uno de esos criterios es la seguridad, y es a lo que nos enfocaremos a lo largo de esta lectura.
SW libre: una realidad.
No invertiremos párrafos enteros analizando si se debe de usar o no el software libre en las corporaciones, ya que en las grandes y las pequeñas su uso es una realidad: desde algunos módulos en códigos de desarrollo, pasando por librerías y claro está, aplicaciones. Desde robustas soluciones como JBoss, hasta programas como FireFox o librerías de Java, difícilmente una organización podría afirmar que se mantiene “libre” del software libre. Inclusive el Departamento de la Defensa de los EUA lejos de negar una realidad, la acepta y mejor decide establece las reglas para su uso (DoD Guidance Regarding Open Source Software).
Ahora bien, entremos en materia. La seguridad del software libre presenta una:
Problemática.
+ El código del software libre está disponible para que “n” personas (principalmente desarrolladores/analistas de seguridad) lo analicen y verifiquen su seguridad, identificando debilidades para su corrección. Lo cierto es que si bien el código está disponible, no hay ninguna garantía de que sea revisado y/o corregido. Tampoco se puede asegurar que el código se revisó por personas conocedoras en la materia. Un código popular como Linux será retomado ciertamente por gente que tratará de identificar sus debilidades, pero no podemos esperar la misma suerte para todo tipo de librerías, miles de rutinas y objetos disponibles en Internet y listos para ser usados en las empresas.
+ No hay un indicador de que el software libre sea más seguro que el software comercial. Ambos casi siempre tienen el objetivo de ser funcionales, mas no necesariamente seguros. ¿En dónde hay más debilidades: en el código libre o comercial? No me atrevería a inclinarme a favor de uno u otro, hay de todo en ambos mundos: los hay con “n” debilidades y los hay con un número reducido de éstas.
+ El código del software libre, al estar disponible, tiene más riesgos ya que al poder ver sus “entrañas”, se pueden descubrir “fácilmente” sus debilidades. Pues bien, como es sabido, no se tiene disponible el código de aplicaciones comerciales y también se pueden identificar debilidades si uno sabe lo que hace.
+ Al estar disponible el código fuente, es posible alterarlo para insertar una puerta trasera o un troyano y (por ejemplo) re-publicarlo en otro sitio para que se baje. Por otro lado, se supone que el software comercial “jamás” traería una puerta trasera si uno lo adquiere legalmente del fabricante; al menos eso dice la teoría.
+ El software libre no siempre tiene un responsable y muchas veces nos podemos encontrar con comunidades sin nada más que buenas intenciones y que se encargan de actualizar el software para corregir vulnerabilidades. No hay a quien reclamarle (o no es práctico hacerlo) ni a quien exigirle. En el software comercial, habrá un fabricante o proveedor con quien inclusive exista un contrato de por medio. Uno de los casos excepcionales podría ser por ejemplo el software libre de RedHat donde hay sí hay una entidad responsable con quien se pueden hacer tratos formales.
Ok, qué hacer?
Ya vimos un panorama resumido de la problemática que se puede presentar en relación a la seguridad del software libre; pues bien, y ahora qué hacemos? ¿Cómo lo incorporamos de manera segura al desarrollo corporativo?
+ Registro del SW libre usado en la empresa. Nos referimos a tener identificado claramente dónde se está usando el software libre dentro de la empresa: ¿es un módulo dentro de un código? ¿Es una librería? ¿Es una aplicación? Se debería de saber en todo momento ubicar este software dentro del SW desarrollado en la corporación. El objetivo de tenerlo identificado es que será mucho más sencillo actualizarlo cuando exista una nueva versión que dé solución a debilidades. Otra ventaja sería poder identificarlo ante una auditoría (ok, creo ningún auditor en México lo pediría, sólo digo que si yo lo fuera, lo haría) : -).
+ Analizarlo con una herramienta automatizada sería un “must”. En el mercado existen diversas herramientas que revisan el código fuente en busca de vulnerabilidades; se pueden encontrar varias opciones en el “Gartner Magic Quadrant for Static Application Security Testing”. La idea sería correrle una de estas herramientas al código y tomar una acción adecuada con las debilidades encontradas.
+ Capacitación en codificación segura. Idealmente todos los desarrolladores deberían estar capacitados en cómo codificar de manera segura para evitar vulnerabilidades. Y al menos uno de ellos debería de estar mucho muy bien capacitado y más que desarrollar, su papel se convertiría en el de “revisor”. ¿Todo esto suena como a un “sí claro, con qué dinero”? Ok, por eso usé la palabra “idealmente”. Y por cierto, aunque es la medida que menos podría ser llevada a cabo de las aquí mencionadas ($), realmente es una de las opciones más beneficiosas.
+ Reputación. ¿Se podría tener un listado de las fuentes (sitios) confiables desde donde se puede bajar software libre? Tal vez este listado se crearía y mantendría entre el área de seguridad y la de desarrollo.
+ Documentación de características de seguridad. ¿El desarrollador que puso a disposición el software libre se preocupó por documentar las características de seguridad de su código? Esto sería un indicador de que al menos existe esta preocupación por parte del creador y nosotros podríamos revisar esas características para ver si son adecuadas para el negocio.
+ Contacto para solucionar debilidades. Si alguien en Internet encuentra una debilidad en el código del software libre, es posible contactar exitosamente al creador o comunidad del SW para informarle de la debilidad con el fin de que se le dé solución? Si no se puede establecer contacto, nos quedaríamos con una pieza de SW libre desactualizado y sin mantenimiento: cualquier debilidad identificada probablemente no se solucionaría (a menos que sea retomada por alguien más). Si no hay manera de contactar, no hay intención de actualizar.
+ Preferir código fuente sobre binarios: al menos con el código fuente tenemos la oportunidad de revisarlo; con los binarios no sabes lo que estás bajando (o es mucho más difícil averiguarlo).
+ Nessus y Wireshark. No está de más que una vez que el software libre se pone en operación se le pase un Nessus a ver si lograra encontrar alguna debilidad y por otro lado poner un sniffer como Wireshark para ver si -en un periodo de algunos días- el código instalado no ha llamado a la nave nodriza.
Conclusiones (al fin).
¡Uf! Sí que fue una entrada extensa, pero de vez en cuando no hace daño (espero no haberlos aburrido). He descrito algunos puntos de la problemática de usar software libre de manera segura en las corporaciones; no todas pueden ser relevantes para todo tipo de empresas y claro, se pueden encontrar más. Lo mismo para las medidas propuestas, algunas aplican, otras no. De todo lo que se leyó, qué te sirve a ti para tu empresa? Eso es lo más importante. O si nada te sirve pero te preocupó el tema para discutirlo en tu empresa, me doy por bien servido. Nos vemos en línea www.twitter.com/FaustoCepeda.
Documentos de Interés:
Fortify: CISO's Guide To Open Source Software Security.
SANS: Security Concerns in Using Open Source Software for Enterprise Requirements.
Coverity: Scan Open Source Report 2009.
Secure Programming for Linux and Unix HOWTO: Is Open Source Good for Security?
Fortify: Open Source Security Study.
No hay comentarios:
Publicar un comentario