Comunicado conjunto sobre la seguridad de GNU/Linux

4 de abril de 2004

Resumen

Los productores de GNU/Linux Debian, Mandrake, Red Hat y SUSE se han unido para dar una respuesta común al informe de Forrester titulado "Is Linux more Secure than Windows?" («¿Es Linux más seguro que Windows?»). A pesar de que el estudio afirma proporcionar un juicio cualitativo de las reacciones de los productores a vulnerabilidades serias, las trata todas como iguales, sin importar su riesgo para el usuario. Como resultado, las conclusiones extraídas por Forrester tienen un valor extremadamente limitado en el mundo real para los consumidores a la hora de asesorarles sobre el asunto de cuán rápidamente se corrigen dichas vulnerabilidades.

Comunicado completo

Los equipos de respuesta de seguridad de los distribuidores de GNU/Linux Debian, Mandrakesoft, Red Hat y SUSE han ayudado a Forrester en la recolección y corrección de datos sobre vulnerabilidades en sus productos. Forrester ha usado los datos obtenidos para elaborar un informe que se tituló "Is Linux more secure than Windows?" («¿Es Linux más seguro que Windows?»). Mientras que se consideran suficientemente correctos y útiles los datos sobre vulnerabilidades referentes a GNU/Linux que son la base de este informe, Debian, Mandrakesoft, Red Hat y SUSE, en adelante «nosotros», estamos preocupados sobre la corrección de las conclusiones obtenidas en el informe.

Creemos que es del interés de nuestros usuarios y de la comunidad del Software Libre contestar el informe de Forrester en la forma de un comunicado conjunto:

Forreter contactó con nosotros en febrero de 2004 para obtener ayuda en la tarea de refinar sus datos brutos. Forrester recogió datos sobre las vulnerabilidades que afectaron a GNU/Linux durante el periodo de un año (junio de 2002 a mayo de 2003) y observó cuántos días nos llevó proporcionar correcciones a nuestros usuarios. Se han invertido importantes esfuerzos no sólo en asegurarnos de que el conjunto subyacente de datos sobre las vulnerabilidades era correcto, sino también en articular el cuidado especial técnico y organizacional puesto en los procesos de respuesta en el campo de la seguridad profesional del Software Libre. Nuestros usuarios aprecian mucho esta pericia, ya que añade gran valor a nuestros productos, pero vemos que la mayoría de este valor ha sido ignorado en los métodos usados para el análisis de los datos sobre vulnerabilidades, conduciendo a conclusiones erróneas.

Nuestros Equipos de Respuesta de Seguridad y organizaciones especializadas en seguridad de respetable reputación (como CERT/DHS, BSI, NIST, NISCC) intercambian información sobre vulnerabilidades y cooperan en las medidas y procedimientos con los que reaccionar ante ellas. Se investiga y evalúa cada vulnerabilidad de forma individual; cada equipo determina entonces su importancia basándose en su riesgo e impacto, así como otras propiedades, principalmente técnicas, de la debilidad del software afectado. Esta importancia se usa entonces para determinar la prioridad con la que se va a trabajar en una solución para la vulnerabilidad, comparándola con la de otras vulnerabilidades pendientes de resolución. Nuestros usuarios sabrán que en el caso de fallos críticos podemos responder en cuestión de horas. Esta priorización implica que los problemas de menor importancia a menudo se verán retrasados para permitir que se resuelvan antes los más importantes.

Incluso aunque el informe de Forrester lo afirma, no hace esa distinción cuando mide el tiempo transcurrido entre el conocimiento público de un fallo de seguridad y la disponibilidad de solución por parte de un vendedor. Por cada productor, el informe tan sólo aporta una simple media, la "All/Distribution days of risk" (días de riesgo Totales/por Distribución), que no da una imagen conclusiva de la realidad que experimentan los usuarios. La media trata de forma errónea todas las vulnerabilidades como iguales, independientemente del riesgo que representan. No todas las vulnerabilidades tienen un impacto igual sobre todos los usuarios. Se ha hecho un intento de asignar a las vulnerabilidades una importancia usando datos de terceros, sin embargo la clasificación de vulnerabilidades de «gran importancia» no es suficiente: el mero hecho de que una organización de seguridad particular anuncie una vulnerabilidad no la convierte en importante necesariamente (de forma similar, la capacidad de explotar una debilidad mediante la red -de forma remota-, a menudo es irrelevante a la importancia de la vulnerabilidad).

Creemos que el informe no trata a los vendedores de Software Libre y al único vendedor de software cerrado de la misma manera. El Software Libre es conocido por su variedad y libertad de elección entre los estándares que define. Habitualmente se ofrecen múltiples implementaciones de estos estándares tanto para el uso de escritorio como de servidor, lo cual da a los usuarios la libertad de escoger el software basándose en su propio criterio, en lugar de en el del vendedor. La apertura, transparencia y verificabilidad del código fuente es un valor añadido junto a la mayor variedad disponible de paquetes de software. Por último, la afirmación de que uno de los vendedores de software ha corregido el 100% de sus fallos durante el periodo del informe debería ser incentivo para una investigación más minuciosa de las conclusiones que presenta el informe.

firmado,
Noah Meyerhans, Debian
Vincent Danen, Mandrakesoft
Mark J Cox, Red Hat
Roman Drahtmüller, SUSE

Información adicional:

Javier Fernández-Sanguino Peña preparó en 2001 un estudio y descubrió que al equipo de seguridad de Debian le había llevado una media de 35 días corregir las vulnerabilidades anunciadas en la lista de Bugtraq. Sin embargo, más del 50% de las vulnerabilidades fueron corregidas en un lapso de 10 días, ¡y sobre el 15% de ellas lo fueron el mismo día que se publicó el aviso! Sin embargo, para este análisis se trataron todas las vulnerabilidades por igual.

Javier ha rehecho el estudio basándose en las vulnerabilidades descubiertas entre el 1 de junio de 2002 y el 31 de mayo de 2003, encontrando que la mediana del tiempo transcurrido entre la comunicación de un fallo y la publicación de un aviso incluyendo una corrección era de 13,5 días (la media es de 31,10 días). De nuevo, se realizó este análisis sin clasificar los avisos por sus diferentes prioridades.