martes, mayo 02, 2006

La Receta

La semana pasada y esta llevo hablando mucho del tema de la apertura de código, y como dice el Robé: "Cortame las piernas y aún podré volar", asín que, por lo cualo, os dejo un texto de una participación en Securmatica esta semana pasada de un amigo (se notan las ideas) y que tiene un estudio de un Security Researcher, que está pa examinarnos de él!:

"Existe en los medios especializados cierto debate sobre la incidencia del modelo de apertura del código, en la seguridad del mismo.

Si bien resulta un debate interesante, quizá pueda estar parcialmente incompleto dado que la apertura o no del código como criterio de seguridad tiene una relevancia muy relativa respecto a la totalidad de factores que la afectan de forma muy determinante.

Algunos miembros de las comunidades Open-Source argumentan que el código abierto es más seguro porque las vulnerabilidades son mas fáciles de detectar y corregir. Sin embargo, la comunidad de Software cerrado (o compartido) argumenta que el acceso al código facilita la labor a los atacantes.

En cualquier caso, no debemos caer en el error de simplificar de esta manera el problema.

Algunos estudios recientes (Cambridge University, Ross Anderson)
http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/toulousebook.pdf
apuntan a que la apertura del código, ayuda de forma similar a “atacantes” (pueden desarrollar exploits más fácilmente) y “defensores” (pueden encontrar bugs y corregirlos mas fácilmente). El estudio concluye que, en un mundo perfecto, y en sistemas suficientemente amplios y complejos para que tenga sentido la aplicación de un modelo estadístico, el atacante y el defensor son afectados por igual por la apertura del código.

Sin embargo, los factores “humanos” juegan un papel mucho más determinante. Son los que realmente rompen esta simetría sustancialmente. ¿Porque fracasan con frecuencia los intentos de la comunidad open Source de establecer un modelo permanente y predecible de revisión de código?

Security focus aporta algunas respuestas al respecto basadas en experiencias reales (
http://www.securityfocus.com/columnists/218) donde el principal fracaso reside en la falta de estímulo o motivación de los programadores para hacer el trabajo “pesado”, “sistemático” y continuo que supone una autentica auditoria de Software. En su lugar, es mas atractivo encontrar vulnerabilidades, explotarlas, y obtener el reconocimiento del resto de la comunidad.
La única contribución puntual que alimentó el proyecto, pero que no evitó su fracaso, vino del mundo académico y de entornos sin demasiada experiencia (estudiantes bajo la supervisión de un profesor)

[Extraido del artículo: "In discussing Sardonix's fall, Crispin Cowan, the project's leader, was harsh in his appraisal of the open-source community: he asserted that security researchers were only interested in finding splashy bugs and posting them to security mailing lists. I think that's oversimplifying the matter.Members of the security community tend to audit software either for a business interest, or for their own private use. Some of them do, indeed, disclose the issues they discover to mailing lists, winning reputations as Kung Fu masters. But many sit on their findings, because kudos on a mailing list or a software auditing website can never compare to the reward of unauthorized access to a high-profile system."]



Sin embargo, el modelo de código compartido, muy extendido entre los fabricantes de software, parte de diferentes conceptos:

1.- Los “ojos” que revisan el código han de ser los necesarios, pero EXPERTOS. Así como no dejar ninguna duda sobre la existencia de “motivación” o “estímulo”.
2.- La revisión de código es sólo una parte de una aproximación global. En el caso de Microsoft, hablamos del Secure Development LifeCycle (SDL). Durante el proceso de desarrollo se incluyen desarrollos de “modelos de amenazas”; herramientas de análisis de código; reviews y chequeos de seguridad durante los “Security pushes”; final security reviews por terceras partes. Etc..
En resumen, la apertura o no del código por si misma no es un criterio de seguridad. Los “atacantes” y “defensores” se pueden ver afectados por igual. Los entornos de desarrollo y teesteo en los que se producen ambos modelos, si tienen algunas diferencias evidentes que rompen esa simetría a favor de los modelos profesionales de desarrollo. No en vano, un entorno profesional dedica un 1% del tiempo destinado a resolver una incidencia de seguridad a su desarrollo, mientras que el 99% restante se dedica a pruebas intensivas"

15 comentarios:

Anónimo dijo...

Al ser básicamente imposible establecer una métrica exacta para medir la calidad/Seguridad del software libre vs. propietario, el debate no deja de ser (y ojo, por las 2 partes) absolutamente subjetivo.
Si a tí te untan con un montón de pasta y y lo hago por amor al arte o por reconocimiento, no implica en ningún caso que tú vayas a ser más experto que yo (y viceversa).
Sea por lo que fuere los dos modelos de desarrollo funcionan, cada cual con sus cositas: ahí van mi máximas (tómese cual postulado del anónimo, igual de válidas que cualquier estudio siempre marcado por sus intereses económicos) ¿o no?:

El en sw. libre, se resuelven antes los bugs, por que si no lo hace el responsable del proyecto, lo puede hacer el que lo encontró, o el que lo publica, y si no la empresa de seguridad X, y si la Y.. ¡todos tienen el código! [1]

De todas formas.. lo del codigo propietario O "codigo compartido".. hablamos de "emule-compartido".. ¿?


[1]http://news.com.com/2100-1002_3-6057669.html

Chema Alonso dijo...

mmm, noticia buena y mala, la mala es que no te lees mi blog desde hace mucho, la buena es que tenemos nuevos amigos aquí ;) Ya hable de esto en Aracnofobia, http://elladodelmal.blogspot.com/2006/03/aracnofobia.html

La pregunta es: Sabiendo como sabemos que Microsoft usa este tipo de herramientas desde hace tiempo y el artículo dice que una vez utilizadas ya están todos los proyectos bug free, podremos inferir que Microsoft tiene todo su software bug free también? O es que Microsoft son peor?

Respuesta: Menos grandilocuencia en el artículo, pq no hay nada perfecto y por tanto nada bug free.

Anónimo dijo...

Intentaba enfocar la idea desde otro prisma, y es que ya que TODOS los proyectos son imperfectos (y si no, que tire la primera piedra :P) la rapidez con la que se corrigen los bugs conocidos es fundamental. Y en esto, me parece, un desarrollo abierto tiene las de ganar, por los motivos que expuse.

En el post anterior pretendía ser irónico.. quizá le falten un par smiley's.. :-S

Anónimo dijo...

Que capullada

Chema Alonso dijo...

Ja,ja,ja. Estoy de acuerdo, esto es una capullada.

Por cierto, que es mejor, la velocidad o que se haga bien?. Para el parche del WMF Microsoft lo hizo en 3 horas y pasó más de 720.000 pruebas sobre los hardwares compatibles, pruebas de impresión, multiples idiomas, .... y para las empresas la planificación en la gestión de actualizaciones es importantísima o ... podemos hacerles parchear cada 4 días 2000 equipos a una empresa? Publicar un parche es ayudar a generar el exploit, si los clientes no les damos ayuda a que parcheen estamos generando problemas, pero... Ya le dedicaré un post completo a los sistemas de actualización de parches. Bies!!

Anónimo dijo...

Oye dejate de repartir propaganda de tu empleador.

Lo cierto es que Microsoft es el unico fabricante de software que sigue teniendo problemas sistematicos en su proceso de ingenieria de software. Puedes aducir todas lo que te de la gana e inventarte todo lo que quieras, pero la gente ya se ha dado cuenta de que el emperador esta desnudo.

Cuantos agujeros tiene que tener Internet explorer para que gente como tu dejen de hablar estupideces?

No hay nadie que confie en la estabilidad o la seguridad de Windows, pero discutir contigo de esto no tiene sentido porque te pagan para que desinformes.

Chema Alonso dijo...

Bueno, tranquilidad, si no te gusta lo que digo solo tienes que darme algún dato y discutimos sobre otras estupideces que no sean las mias, o en otro blog, que hay muchos llenos de "verdades" por ahí.

Que no te gusta de este post? dame algún dato amigo. y los datos no tienen pq ser una ofensa personal!!! ;)

"Emperador desnudo"? En las conferencias de Black Hack, no piensan así, ni los expedientes de seguridad dicen eso, ni los estudios, pero...

Vente a alguna conferencia y hablamos.

Respecto a que nadie confia en la seguridad y estabilidad de windows supongo que sabras que la bolsa de Madrid y la de Valencia van en Windows por ponerte un par de ejemplos de estabilidad y disponibilidad y... bueno, para que te voy a contar mi vida.

Ah y no trabajo en Microsoft, y antes de ser MVP ya estaba con temas de seguridad.

PD: Si sabes contar los de IE sabrás contar los de Firefox,no?


Toma, la versión 1.0 que salio con IE 6 SP2 ha tenido..., cuenta, cuenta:

http://www.securityfocus.com/cgi-bin/index.cgi?o=0&l=70&c=12&op=display_list&vendor=Mozilla&version=1.0&title=Firefox&CVE=

Anónimo dijo...

ummm.. esto.... mis fotos tienen licencia GPL, así que hay que nombrar la fuente.

jejeje, a ke te he sakau guapo, eh!

gogoz

Anónimo dijo...

¿Y si comparas la última versión de Firefox con la última de Explorer?

Digo en cuanto a vulnerabilidades, no en cuanto a tecnología. Bueno, si quieres también, venga va.

Chema Alonso dijo...

Puedes hacer el cáculo compañero del metal, pero para ello debes tener claro la diferencia entre versión y actualización de seguridad, pq la última de explorer (con sus últimas actualizaciones), es decir la de hace un mes debe ser comparada con la última de firefox, con la de hace unos días y saldrá que tienen una o ninguna. Ya sabéis lo que suelo decir en mis charlas, cuidado con las estádisticas, entidades comparables, datos comparables. Pero, como ya estoy harto del debate Firefox, IE le dedicaré un post completo y me pones allí todos los comentarios, ok? Voy a dar por cerrado este post ya que ya es horita.

Anónimo dijo...

Security Focus le dedica a Microsoft Internet Explorer SP2 un total de tres páginas para el solo, sin embargo para Mozilla Firefox 1.5.3 no hay ninguna.

Seguramente (no suelo consultar esta web) como tú dices de los de IE habrá que restar alguno o bastantes para los que ya se habrá publicado parches en su magnífica política de hacerlo una vez al mes.

Esto para mi es importante porque nos lleva al verdadero "quid" de la cuestión, que no es tanto cuantos salen en Security Focus (más, añado, los que no salen "nunca" con la fantástica idea de seguridad por ocultación), sino la forma de atacarlos, rapidez, efectividad (que los parches no tapen unos agujeros para abrir otros, etc).

Y supongo que para muchos usuarios o empresas preferirán ver una barra de progreso instalando un parche que cruzar los dedos hasta que el martes X de cada mes se publiquen.

Chema Alonso dijo...

A ver amigo, La versión de Firefox es la 1 (que es un major release), las siguientes son actualizaciones, y sale una cada poco, de hay hasta minors releases (1.1.x, 1.2.x) y cada puntito posterior son actualizaciones. IE 6 SP2 es de Septiembre de 2004, justo cuando salió Firefox 1.0, mismo tiempo de la misma versión. MS en lugar de poner IE 6.1.2.3 SP2 se le cataloga como IE 6sp2. Si ves en ayuda, acerca de, verás la versión exacta. Elige el tramo de tiempo en mismos, elige las versiones que salieron juntas (ma o meno) y echa tus numeros.

La política de parches de MS?? Mira, el otro día estaba con el director de TI de una empresa que tenía linux en unas confs y mira, sin avisar aparecieron 5 vulnerabilidades críticas de linux kernel, solo era viernes y no tenía gente. Empezó a llamar a sus chicos, etc...

Mejor saber cuando salen, no?

rapidez, efectividad? Veo que eres un experto, dame datos, cuanto de más rápido, cuanto de más efectivo y en que unidades.

ODIO la discusión de navegadores, ya hablaremos en otro post de ello. Oye, tio, código abierto, pon tu mail y así nos conocemos!

Un saludete!!

Anónimo dijo...

Claro que es mejor saber cuando sale el parche! no te jode...
Pero que es mejor ¿esperar con la vulnerabilidad en tu server hasta el segundo (primer, tercera,... me la suda) martes de cada mes a que llegue el parche, o que estos vayan llegando segun se van publicando, con la unica espera de esperar a que llegue el tecnico para instalar la actualización. En el ejemplo que comentas, el lunes se actualizaria el server y listo. Si fuese microsoft y estuviesemos miercoles 13 de marzo, tendrias que esperar casi un mes a que te llegue el parche.
¿cual d elos dos sistemas es mejor?
de topdas maneras, este es un debate falso, ya que el debate SL vs SP no es técnico sino filosofico. Estamos hablando de politicas de actualizaciónes, que dependen de cada compañia, por lo que la de mocosoft, oracle, la de sun o la de ubuntu difieren, pero no es ese el debate (y lo sabes :-p)

gogoz

Chema Alonso dijo...

Anderrrrr!!!, verás. Cuando una vulnerabilidad es crítica y pública, Microsoft la publica en el acto. Es lo que se denomina Responsible Disclousure. Ya haré un buen "pink papper" sobre los sistemas de actualización en MS, ahora te pongo otro post....!

Anónimo dijo...

¿Y el post de navegadores?

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares