¡Qué malévolos estos chicos de Fortify!. Resulta que estos amigos que se dedican a vender productos de seguridad para empresas han hecho un estudio sobre 11 proyectos Open Source en Java. Ellos tienen una herramienta de análisis estático de código llamada Java Open Review (JOR) que es gratutia y supongo que querían ver si alguien la estaba utilizando. Pobres, que decepción, parece que la respuesta es NO. Los proyectos elegidos han sido:
Los 11 proyectos Open Source Java evaluados
Cómo se puede ver 11 proyectos "pequeños y de poco uso" o todo lo contrario. El estudio revela que casi todas las comunidades fallan a la hora de proveer a los usuarios ayuda para como remediar las vulnerabilidades y los riesgos de seguridad mediante el contacto con expertos de seguridad en el proyecto y mediante la documentación. Además, se evalúan las tendencias, para ver si versión a versión se van corriguiendo los fallos, pero no, parece que es totalmente anárquico, cuando no creciente, el número de fallos detectado en versiones consecutivas.
El estudio viene acompañado de algunas perlas dignas de ser puestas como aparacen, sin ninguna de las manipulaciones típicas que suelo hacer yo aquí en el lado del mal.
"El software open source puede ser otra opción de valor en las empresas hoy en día, pero, de igual forma que en el software comercial, las vulnerabilidades de software deben ser un punto de preocupación para los CIOs delas empresas que dependen de software open source en su negocio. Este es un mal endémico que comienza en las comunidades open source, y mientras el software open source no se enfrente a las vulnerabilidades como el software comercial o el software desarrollado internamente, los mecanismos de prueba y análisis de código necesitan ser realizados con gran rigor en las comunidades open source para influir en procesos de desarrollo seguro", según Howard A. Schmidt, consejero de ciber seguridad de la Casa Blanca.
Para hacer el estudio y medir el nivel de conocimiento de seguridad ofrecido a los usuarios y medir la seguridad de los procesos de desarrollo, Fortify interactuo con los mantenedores del software y examinó las practicas de seguridad documentadas. Además, se descargaron multiples verisones de los paquetes y se escanearon con una herramienta de análisis de código estático.
"Although enterprise adoption of OSS has steadily increased, little has been done within the OSS community to implement enterprise-worthy application security measures"
Vamos, que aunque la adopción de productos open source ha crecido continuamente, poco ha sido hecho en las comunidades open source para implementar medidas de seguridad de valor en las empresas.
El estudio recomienda aplicar en las empresas herramientas de análisis estático de código, es decir, que las herramientas de análisis de código no sean sólo para los desarrolladores de software sino también para las empresas que implantan productos open source. No es que no se fien de las prácticas de desarrollo seguro que implementan los proyectos open source, es que el estudio les ha dicho que no es fiable fiarse de las prácticas de desarrollo seguro que implementan muchos proyectos open source.
"Most open source communities do not follow enterprise-level change control standards"
"La mayoría de las comunidades open source no siguen estándares para el control de cambios a un nivel empresarial", según Jennifer Bayuk, consultora de seguridad y responsable de seguridad de Bear Stearns y que dijo la frase más maligna de todo el artículo:
"There is a hidden cost for the enterprise in using open source because they have to test and patch for security bugs they don't anticipate."
"Hay un coste oculto para las empresas que están usando open source porque ellos tienen que testear y parchear los fallos de seguridad que ellos (las comunidades open source) no hacen por anticipado"
Y estos son algunos de los datos.
Fallo a la hora de proveer acceso a expertos de seguridad
Para evaluar esta parte se comprueba que haya documentación que cubran las implicaciones de seguridad y el desarrollo seguro del software que ellos desarrollen, una dirección de e-mail para que los usuarios pueda reportar vulnerabilidades de seguridad y acceso a expertos de seguridad internos para hablar sobre temas de seguridad relativos al producto. Ahí van los resultados:
Sólo pasa este test Tomcat
Fallo a la hora de adoptar un proceso de desarrollo seguro
En casi todos los proyectos analizados se comprueba que las vulnerabiliades permanecen versión tras versión, algunas veces, durante más de una año. Se puede ver que las vulnerabilidades crecen significativamente o permanecen constante. Esto demuestra que no se sigue un modelo de desarrollo seguro de software.
Los bugs o se mantienen o crecen
Fallo a la hora de tratar las vulnerabilidades de seguridad
El número de vulnerabilidades descubiertas ha sido sorpendente. Sobre todo teniendo en cuenta las dos más populares y que han sido remarcadas por todos los desarrolladores. Cross-Site Scripting y SQL Injection. Parece mentira este dato tratándose del software que se está analizando.
Mas de 22.000 XSS y 15.000 SQLi. INCREIBLE
Al final, la ausencia de una preocupación real del problema hace que los resultados en estos once proyectos sean más que llamativos con unos números de fallos por cada mil lineas de código muy elevados y, cómo dice el informe, hubiera bastado con utilizar JOR o Findbugs herramienta open source, para poder deterctar esta ingente cantidad de fallos de XSS y SQLi (entre otras).
Mas de 10 bugs introducidos en cada 1.000 líneas de código en media
No es este el primer informe que intenta hacer hincapié en la necesidad de aplicar buenas prácticas de desarrollo en el Open Source. Ya lo hizo con anterioridad Ben Chelf, CTO de Coverity y se quejó de esto Negroponte.
Al final, el mito de muchos ojos mirando no vale, no importa la cantidad, sino la calidad de los procesos.
Puedes descargarte el informe de la siguiente URL: Fortify Open Source Report
Saludos Malignos!
Los 11 proyectos Open Source Java evaluadosCómo se puede ver 11 proyectos "pequeños y de poco uso" o todo lo contrario. El estudio revela que casi todas las comunidades fallan a la hora de proveer a los usuarios ayuda para como remediar las vulnerabilidades y los riesgos de seguridad mediante el contacto con expertos de seguridad en el proyecto y mediante la documentación. Además, se evalúan las tendencias, para ver si versión a versión se van corriguiendo los fallos, pero no, parece que es totalmente anárquico, cuando no creciente, el número de fallos detectado en versiones consecutivas.
El estudio viene acompañado de algunas perlas dignas de ser puestas como aparacen, sin ninguna de las manipulaciones típicas que suelo hacer yo aquí en el lado del mal.
"El software open source puede ser otra opción de valor en las empresas hoy en día, pero, de igual forma que en el software comercial, las vulnerabilidades de software deben ser un punto de preocupación para los CIOs delas empresas que dependen de software open source en su negocio. Este es un mal endémico que comienza en las comunidades open source, y mientras el software open source no se enfrente a las vulnerabilidades como el software comercial o el software desarrollado internamente, los mecanismos de prueba y análisis de código necesitan ser realizados con gran rigor en las comunidades open source para influir en procesos de desarrollo seguro", según Howard A. Schmidt, consejero de ciber seguridad de la Casa Blanca.
Para hacer el estudio y medir el nivel de conocimiento de seguridad ofrecido a los usuarios y medir la seguridad de los procesos de desarrollo, Fortify interactuo con los mantenedores del software y examinó las practicas de seguridad documentadas. Además, se descargaron multiples verisones de los paquetes y se escanearon con una herramienta de análisis de código estático.
"Although enterprise adoption of OSS has steadily increased, little has been done within the OSS community to implement enterprise-worthy application security measures"
Vamos, que aunque la adopción de productos open source ha crecido continuamente, poco ha sido hecho en las comunidades open source para implementar medidas de seguridad de valor en las empresas.
El estudio recomienda aplicar en las empresas herramientas de análisis estático de código, es decir, que las herramientas de análisis de código no sean sólo para los desarrolladores de software sino también para las empresas que implantan productos open source. No es que no se fien de las prácticas de desarrollo seguro que implementan los proyectos open source, es que el estudio les ha dicho que no es fiable fiarse de las prácticas de desarrollo seguro que implementan muchos proyectos open source.
"Most open source communities do not follow enterprise-level change control standards"
"La mayoría de las comunidades open source no siguen estándares para el control de cambios a un nivel empresarial", según Jennifer Bayuk, consultora de seguridad y responsable de seguridad de Bear Stearns y que dijo la frase más maligna de todo el artículo:
"There is a hidden cost for the enterprise in using open source because they have to test and patch for security bugs they don't anticipate."
"Hay un coste oculto para las empresas que están usando open source porque ellos tienen que testear y parchear los fallos de seguridad que ellos (las comunidades open source) no hacen por anticipado"
Y estos son algunos de los datos.
Fallo a la hora de proveer acceso a expertos de seguridad
Para evaluar esta parte se comprueba que haya documentación que cubran las implicaciones de seguridad y el desarrollo seguro del software que ellos desarrollen, una dirección de e-mail para que los usuarios pueda reportar vulnerabilidades de seguridad y acceso a expertos de seguridad internos para hablar sobre temas de seguridad relativos al producto. Ahí van los resultados:
Sólo pasa este test TomcatFallo a la hora de adoptar un proceso de desarrollo seguro
En casi todos los proyectos analizados se comprueba que las vulnerabiliades permanecen versión tras versión, algunas veces, durante más de una año. Se puede ver que las vulnerabilidades crecen significativamente o permanecen constante. Esto demuestra que no se sigue un modelo de desarrollo seguro de software.
Los bugs o se mantienen o crecenFallo a la hora de tratar las vulnerabilidades de seguridad
El número de vulnerabilidades descubiertas ha sido sorpendente. Sobre todo teniendo en cuenta las dos más populares y que han sido remarcadas por todos los desarrolladores. Cross-Site Scripting y SQL Injection. Parece mentira este dato tratándose del software que se está analizando.
Mas de 22.000 XSS y 15.000 SQLi. INCREIBLEAl final, la ausencia de una preocupación real del problema hace que los resultados en estos once proyectos sean más que llamativos con unos números de fallos por cada mil lineas de código muy elevados y, cómo dice el informe, hubiera bastado con utilizar JOR o Findbugs herramienta open source, para poder deterctar esta ingente cantidad de fallos de XSS y SQLi (entre otras).
Mas de 10 bugs introducidos en cada 1.000 líneas de código en mediaNo es este el primer informe que intenta hacer hincapié en la necesidad de aplicar buenas prácticas de desarrollo en el Open Source. Ya lo hizo con anterioridad Ben Chelf, CTO de Coverity y se quejó de esto Negroponte.
Al final, el mito de muchos ojos mirando no vale, no importa la cantidad, sino la calidad de los procesos.
Puedes descargarte el informe de la siguiente URL: Fortify Open Source Report
Saludos Malignos!
Me parece una pena que habiendo tanta gente con talento dedicada al desarrollo de software libre estas cosas se dejen tán de lado.
ResponderEliminarPienso que unos conocimientos minimos de correcta programación y desarrollo seguro deberian ser parte imprescindible de cualquier proyecto.
Además habiendo proyectos Open Source que han demostrado una buena metodología como OpenBSD, se pueden aprovechar como patrón para el resto.
Quiza sea mi ignorancia la que lo haga parecer tán simple...
...la gente se inventa estadisticas con tal de intentar demostrar algo y eso lo sabe el 14% de la gente. (Homer Simpson)
ResponderEliminar... Bien dicen que un admin paranoico vale por dos, y con este estudio has puesto paranoico a mas de alguno, pero que hay en el otro lado de la moneda, que hay en la contraparte de estos programas..
ResponderEliminarInteresante, solo recuerdo lo que escribiste hace poco, ¿Cuántos fallos de seguriad no son tales fallos?
Bueno, primero hay que saber si el autor del informe puede ser totalmente imparcial al cargar las tintas contra el software libre.
ResponderEliminarPodemos ver aquí que antes que para la Casa Blanca ha trabajado para Microsoft.
Exactamente su biografía dice:
"Prior to the White House, Howard Schmidt was chief security officer for Microsoft Corp., where his duties included CISO, CSO and forming and directing the Trustworthy Computing Security Strategies Group".
@mikelats, ese tipo no es el que ha hecho el informe, símplemente han cogido una quote suya. El informe está firmado por una persona de Fortify.
ResponderEliminarSaludos!
Cantidad y calidad son conceptos sólo aplicables a las drogas y parece que vosotros os ponéis como las cabras.
ResponderEliminarPerdón,
ResponderEliminarHe leído el post a toda leche y no me he dado cuenta.
Saludos.
Un informe con datos y más técnico hubiese sido mucho mejor que este escrito que parece ir dirigido a los políticos de la Unión Europea que han dedicido apostar por el open source.
ResponderEliminarPor lo que sebería de apostar es por los buenos programas, independientemente de la licencia que tengan.
El informe parece hecho para asustar, por ejemplo no dice que Hibernate tenga errores de sqlinjection, pero si que dice que entre todos los proyectos hay muchos errores de ese tipo.
Menos mal que trabajo con .net y no uso NHibernate ;).
Lo dicho, el informe me parece muy interesado políticamente.
Un par de cosillas:
ResponderEliminarPrimero, para infi, yo creo que la seguridad en el software no es un problema de buenas prácticas de programación (que también influye, claro), sino de buenos procesos de gestión y control. Todos metemos la pata, y la metemos mil veces, pero ahí es donde tiene que haber un procediemiento de control de calidad (entendiendo la seguridad como parte de los requisitos) para que los productos salgan sin tantos fallos. Y eso son procesos, no excelencia técnica.
En cualquier caso, aunque lo queramos ver como un problema de buenas prácticas de programación, tiene que haber procesos de formación para los programadores, porque si esperamos que aprendan a programar de forma segura por iniciativa propia, al final las cosas salen como salen.
Lo dicho, al final gestión y control, eso es todo.
Segundo, Chema, yo matizaría un poco la estadística de vulnerabilidades porque está totalmente falseada por Hipergate. Decir que la media de los 11 proyectos es de más de 10 problemas por cada KLOC es un poco injusto, porque si quitas Hipergate a mí me sale 1,47 vulnerabilidades por KLOC, que no sé si es mucho o poco pero que no tiene nada que ver con la otra cifra.
@mikelats
ResponderEliminarManual para flames de la FSF
Página 14, artículo 6, parrafo B:
En el extraño caso de que una critica o ataque no pueda ser refutado con argumentos tecnicos o el hacerlo conlleve mas tiempo del deseado, se actuara contra el emisor de los mismos intentando debilitar su credibilidad.
Ejemplos de uso: ISO con OOXML
PD: di edtod diad veid que habo rado no od peocuepeid ed que tendo da dendua metida ed ed cudo de zema.
Un dadudo
Como han dicho antes, habría que ver quién es el que lo dice y cómo andan las contrapartidas en software propietario.
ResponderEliminarEn cualquier caso, hay alguien que creo que no es sospechoso de nada: Linus Torvalds. Y según leo hoy en DiarioTI, acaba de poner a parir al sector de la Seguridad Informática.
http://www.diarioti.com/gate/n.php?id=18574
Es una lástima. Posiblemente tenga razón en parte de lo que dice. Seguro que sí. Pero hay frases que dan que pensar, como "In fact, all the boring normal bugs ar way more important, just because there´s a lot more of them" (o sea, que, realmente, los bugs normales y aburridos son más importantes - que los de seguridad-, ya que su número es mucho mayor).
Técnicamente quizá no le falte razón: La seguridad, como él dice, no es lo único importante y, al fin y al cabo un fallo es un fallo.
Pero alguien de la talla de Linus Torvalds debería pensar de forma estratégica y no como si fuera un "programador por encargo". Un fallo de seguridad no es un fallo.
Es alguien que ve vulnerada su intimidad. Una organización cuya imagen corporativa se deteriora. Son pérdidas económicas. Una puerta de entrada a las mafias y las actividades delictivas. Una Sociedad que pierde la confianza en la Tecnología. ¿Sigo?
Cuando palabras como éstas las pronuncia alguien a quien muchos siguen, el efecto puede ser devastador. Espero que no sirvan de guía a la comunidad de desarrolladores.
En fin, que deseo que todo haya sido un malentendido o una falsa noticia y todo se aclare pronto. Si fuera así, estaría encantado de gritarlo a los cuatro vientos.
Pero, por ahora, estoy decepcionado.
ERG.
Sigo pensando que la mejor política de seguridad es salir de casa con las llaves en la mano.
ResponderEliminar:)
El hecho que sea open source o propietario afecta en la calidad del código? Menuda estupidez, hay software bueno y malo independientemente del tipo de licencia que lleve... si eso fuera así, Windows con la cantidad de recursos disponibles y siendo propietario tendría 0 fallos de seguridad, y creo recordar que "alguno" han encontrado a lo largo de estos años...
ResponderEliminarPor lo que parece el único software perfecto aquí es la herramienta esta de análisis, que no debe dar falsos positivos nunca.
Es decir, que como muchos han advertido, los lenguajes "fáciles" como Java en realidad tienen pegas, una de las cuales es que programadores inútiles, se acostumbren a las malas prácticas y pasa lo que pasa. Cosa que no tiene absolutamente nada que ver con el Open Source.
ResponderEliminarPor cierto, me hace gracia eso de que los miles de ojo mirando en un mito, cuando precisamente gracias a eso, se tienen más facilidades para lo que ha hecho Fortify. A ver si pueden hacer un estudio tan documentado a ciegas con programas propietarios hechos para Puto Net.
amos a programar tos en ensamblador de nuevo que los otros lenguajes son más faciles...
ResponderEliminarpor cierto anonimo ¿que lenguaje utilizas tu mas seguro que .NET?
que por cierto, es tan opensource como java y tienes unos pocos proyectos abiertos en codeplex...
Coño Maligno, habla bien, ni digas "quote", joder.
ResponderEliminar@Maligno: ¿Porqué aún no has publicado nada sobre el tema de moda, DNS? no va con segudas eh... es que acabo de ver la entrada de "una al día" y me he leido también la página del pollo este http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html y quería saber más opiniones, sobretodo en el aspecto "ético" ya que entiendo que, como apuntan en la noticia de hispasec, es curioso como alguien sin saber detalles sobre el error, únicamente sabiendo que hay un error puede tardar mucho menos en descubrir dicho error...
ResponderEliminar¿No nos debería esto hacer pensar que no hay una buena política de investigación, en cuanto a seguridad?
Quizá haya que especializarse, pero claro, ¿quién se ocupa de decidir sobre qué producto debes investigar?
O quizá la idea se siempre suponer que hay un fallo y sólo debes encontrarlo, ha habido concursos de hacking que pretendían eso... los creadores no sabían como resolverlo, pero imaginaban que alguien encontraría algún fallo (manda huevos) :)
@anónimo de Torvalds.
ResponderEliminarLo de las pérdidas, la imagen deteriorada, sociedad que pierde confianza...
Bueno, imagínate una aplicación de compra de entradas que simplemente, al final del proceso de seleccionar las entradas da un error que no te permite comprar. No es ninguna cagada de seguridad, simplemente no funciona correctamente, además de ser dificilmente usable y poco intuitiva.
¿Crees que eso de la confianza, imágen, etc. no se le puede aplicar exactamente igual a un fallo que no es de seguridad?
El problema no es que sea de seguridad o no, el problema es el riesgo, exposición e impacto que tenga el problema, y los de seguridad no tienen porqué ser más peligrosos que otro cualquiera.
@filemaster,
ResponderEliminarAntes he patinado, lo admito. Pero
todo tiene su explicación y es que Maligno con ese título de post tan alarmante me ha confundido en cuanto a la procedencia.
@Maligno,
¡Que no eres bueno! ;-)
En el informe no pone "El crecimiento en la adopción de software open source está poniendo el negocio en mayor riesgo".
Eso es una interpretación que hace pensar que el informe es contrario a la utilización de software libre.
Por supuesto tampoco está en el informe el texto demoledor de Howard A. Schmidt.
Realmente es un informe ejecutivo que primero explica su fijación por el software libre. Dice que su
utilización se extiende y que ellos como empresa proveedoras de software para asegurar la seguridad se ven inmersos en el centro del debate.
Luego describen los fallos más frecuentes que han encontrado en el estudio. Esto lo ha explicado maligno perfectamente.
Por último, lo más importante, las dos conclusiones:
1-Los Gobiernos y empresas comerciales deben utilizar software libre con precaución. Dentro de este punto enumerar tres acciones que se pueden llevar a cabo perfectamente.
2-Los proyectos de software libre deben adoptar prácticas robustas en cuanto a seguridad incluyendo personal, procesos y tecnología.
Terminan con "With these
actions in place, open source communities can then advertise and substantiate effective security practices that will encourage strong adoption. As highlighted earlier in this report, the steps taken by Mozilla are a prototype for open source security.
Bueno eso es todo. Hay cosas que mejorar y también ejemplos a seguir.
Y en cuanto a Gobiernos y empresas asumir que si quieren beneficiarse del software libre con sus licencias por la patilla tienen que realizar un esfuerzo para asegurar la seguridad. Esfuerzo suele significar dinero.
Pero no se dice nada de poner el negocio en mayor riesgo.
Bueno, hay que reconocer que sin hipergate, el informe no sería tan bestia. Aún así, que esos fallos se encuentren con una herramienta gratuita que pueden incorporar a su proceso de desarrollo dice muy poco del proceso de desarrollo.
ResponderEliminar