¿Qué tan seguro es el software de código abierto?

Este artículo estudia detenidamente la relación entre el desarrollo de software de código abierto y la seguridad del software. Las discusiones sobre qué sistemas operativos basados ​​en Microsoft Windows o Linux son más seguros han arrasado en Internet. La discusión involucra los intereses creados y parciales de muchos. Los malentendidos causados ​​por una comprensión insuficiente y errores lógicos provocaron confusión y acaloradas discusiones. Con la esperanza de atraer más atención hacia los patrocinadores como estrategia publicitaria, los periódicos faccionales utilizan datos estadísticos recopilados para parecer demasiado autoritarios y objetivos, lo que en realidad equivale a utilizar sesgos y hechos cuestionables para respaldar las discusiones. Parte de la razón por la que esta discusión aparentemente interminable carece de conclusiones definitivas es que las evaluaciones de seguridad se centran demasiado en un epifenómeno: sólo estudian los fenómenos superficiales del desempeño de la seguridad sin un análisis en profundidad de las razones de las características de seguridad. Parte de la razón es que el desarrollo de software de código abierto es misterioso y nuevo para la mayoría de los proveedores de software propietario. Por lo tanto, estos fabricantes de software que no son de código abierto no pueden comprender los esfuerzos detrás de escena en el mundo del código abierto para abordar los problemas de seguridad. Parte de la razón es que muchas de las personas involucradas en la discusión son usuarios finales con sólo un conocimiento superficial de la seguridad del software. Incluso los expertos en TI a veces no comprenden los esfuerzos realizados por la seguridad del software en la estructura del software y el proceso de desarrollo, porque incluso si los expertos en TI tienen un conocimiento profundo de la configuración de seguridad de la red y el sistema, sus habilidades a menudo no incluyen el desarrollo de software de código abierto y el desarrollo de software. Comprensión práctica de las estructuras. Si quisiera llenar un vacío en la base de conocimientos públicos sobre el impacto de la seguridad del software, probablemente tendría que escribir varios volúmenes grandes de material. Sin embargo, todavía es posible seleccionar un número limitado de temas de esta amplia gama para una introducción aproximada, que es el propósito de este artículo. Al final, el debate sobre seguridad entre Linux y Windows se convirtió en una carrera de ejemplos. Estos incluyen ejemplos más básicos de los beneficios y daños provocados por la seguridad, sirviendo a modelos de desarrollo de código abierto y de código cerrado, respectivamente. Esta no es sólo una cuestión técnica, sino también un evento social. Si se estudia esta discusión más detenidamente, se parece más a un evento para economistas y teóricos de juegos. A estas alturas, el enfoque de desarrollo más incomprendido de los dos en la mayoría de las discusiones es el enfoque de desarrollo de código abierto. Ahora veamos cómo el desarrollo de software de código abierto considera los problemas de seguridad del software. No revelar información es seguro Algunos argumentos dirigidos a la seguridad del software de código abierto se basan en inferencias erróneas. Una de las objeciones más extendidas y que parecen más válidas al software de código abierto es lo que llamamos la falacia de "no divulgación es igual a seguridad". Una de las afirmaciones más comunes es: "Verás lo seguro que es cuando sea tan popular como un programa de Microsoft". Otra es "Cualquier pirata informático de seguridad sofisticado puede ver el código fuente, por lo que no es lo suficientemente seguro". La falacia de "secreto es igual a seguridad" limita la discusión sobre la seguridad relativa de los sistemas operativos basados ​​en Linux y el navegador Mozilla Firefox. La realidad es que "si no es seguro, es público" no puede garantizar realmente la seguridad funcional. Sólo proporciona una apariencia de seguridad; de hecho, los principios de seguridad en los que se basa la comunidad de desarrollo de código abierto son exactamente lo contrario. Este principio también se puede llamar "la apertura es seguridad", que incluye dos principios básicos de seguridad del software: seguridad transparente y seguridad aportada por la popularización. Seguridad transparente La seguridad del desarrollo de software de código abierto a menudo se cuestiona porque el código fuente está disponible para cualquiera. Esta teoría sostiene que las personas que intentan realizar ataques a la seguridad pueden encontrar fallas en el código que pueden constituir debilidades del ataque al estudiar el código fuente, lo que facilita atacar estas debilidades. Esta teoría tiene cierta base, pero no en la forma que uno podría pensar. De hecho, es un trabajo minucioso analizar visualmente el código fuente para encontrar defectos, clasificarlos y crear más defectos. Si es cierto, como dicen, que el software de código abierto es más vulnerable a los ataques debido a la apertura del código fuente, entonces sería imposible que alguien ajeno a Microsoft descubriera algún defecto de IE. De hecho, para cualquier aplicación no trivial, incluso este arduo trabajo es más fácil que encontrar el error mediante técnicas de ingeniería inversa.

Estas técnicas requieren sondear una aplicación en ejecución, ingresar información con formato incorrecto o hacer un mal uso de ella deliberadamente, y luego examinar la escalabilidad y el resultado de la aplicación para determinar cómo y cuándo la operación del programa se desvía de la intención original de la aplicación. Puede llegar un momento en que podamos ingresar el código fuente en otro programa para determinar qué pieza está defectuosa sin tener que usar técnicas de ingeniería inversa para encontrar el defecto, pero incluso si ese día llega, la tarea se puede realizar con la misma facilidad usando un archivo de código de dispositivo binario ejecutable, el código fuente en sí no es necesario en absoluto. Después de todo, lo que se necesita para ese tipo de análisis no es la información que un programador necesita para nombrar una variable o un método, sino la forma en que se construyen los algoritmos utilizados por el software que se analiza. Después de todo, el código del dispositivo en sí es funcionalmente idéntico al código fuente introducido en el compilador. La única diferencia es su confiabilidad para un programador específico. Estadísticamente hablando, este hecho no respalda la afirmación de que el software de código abierto sea inherentemente más defectuoso. Por ejemplo, un informe de la empresa de análisis de código Coverity mostró que encontraron sólo 985 errores en los 5,7 millones de líneas de declaraciones del kernel de Linux. En comparación, un estudio realizado por el laboratorio CyLab de la Universidad Carnegie Mellon mostró que los programas comerciales representativos de código cerrado tienen un promedio de 20 a 30 errores por cada 1.000 líneas de declaraciones. Calculado en base a esta proporción, el número de posibles errores en 5,7 millones de líneas de declaraciones superará los 114.000, que es 114 veces el número de errores en el kernel de Linux. El importante papel de la transparencia del software en el proceso de desarrollo de software de código abierto a menudo se denomina revisión por pares. Este proceso está motivado por el estado público del código fuente y el hecho de que los programadores no pueden estar completamente alineados con los objetivos de una única entidad controladora, como el CEO. Las personas que desarrollan el código fuente deben gestionar las acciones de los demás. Por lo tanto, el raro pero feroz argumento de que los programadores con buenas intenciones pueden dejar "puertas traseras" en los programas ha sido socavado por el proceso de revisión por pares. El código que cumpla estricta y cuidadosamente con los estándares de calidad se aceptará en la base del código del proyecto de software de código abierto. De hecho, si se descubre que un programa es un troyano durante la revisión pública, se señalará. También se puede utilizar software con derechos de propiedad cuyo código fuente no se revela. A veces tiene funciones de rootkit especialmente añadidas, que sólo pueden descubrirse cuando ocurre un accidente, como el famoso incidente del rootkit de Sony en la segunda mitad de 2005. Seguridad a través de la popularidad La popularidad del sistema operativo de escritorio Windows de Microsoft y de IE se utiliza a menudo para explicar la incidencia de defectos e infracciones. Aquí les voy a decir algo de verdad. Para sistemas operativos o navegadores web con código fuente cerrado y derechos de propiedad, una mayor penetración sin duda puede atraer la atención de escritores de códigos maliciosos y otros invitados no invitados. Pero si se adopta un nuevo enfoque de desarrollo centrado en la popularidad, la situación cambiará. El umbral para que el software de código abierto adopte piezas de software específicas es bajo. Debido a que el software de código abierto es completamente independiente del precio, en nuestro mundo similar a una red en constante evolución, un nuevo archivo de instalación de sistema operativo puede costar no más que un CDR en blanco y solo toma unos minutos descargarlo. El método de instalación es diferente e incluso se puede ahorrar dinero para comprar un CD. La naturaleza sencilla y ampliamente aceptada del software de código abierto hace que sea más fácil atraer nuevos desarrolladores para que se unan a un proyecto de software de código abierto. A medida que aumenta el número de usuarios, también aumenta el interés del programador en el proyecto. Los desarrolladores de software de código abierto forman un grupo de usuarios. Además, el software de código abierto aprovecha el tiempo de trabajo de los programadores. No tienen tiempo para dedicarse a un equipo de desarrollo serio, pero pueden utilizar su tiempo de trabajo para buscar y modificar. varios defectos y errores. Como resultado, el número de personas que buscan defectos y errores en el software de código abierto más popular es mucho mayor que los limitados equipos de desarrollo de software de código cerrado. Este número aumenta correspondientemente con el aumento del número de usuarios. El número de personas que encuentran nuevos fallos que explotar es superado por el número de personas que encuentran nuevos fallos que solucionar. Incluso si la persona que encuentra el error no escribe el código para solucionarlo, se lo dice a alguien que sí lo hace.

El resultado de esta situación es claro. La respuesta más rápida documentada de Microsoft a la falla fue el parcheo de la biblioteca WMF a principios de este año, que tomó entre 9 y 9 años, según Debby Fry Wilson, directora del Centro de Respuesta de Seguridad de Microsoft. 10 días. Al mismo tiempo, la Fundación Mozilla produce, prueba y lanza parches para el navegador web Mozilla Firefox según lo previsto con no más de una semana de diferencia. El tiempo de aplicación de parches para el kernel de Linux ni siquiera lleva días, sino que se mide en horas. Esto se debe principalmente a la amplia base masiva de pruebas de parches: Debby Fry Wilson, hablando del rápido lanzamiento de los parches WMF, dijo que las pruebas, más que el desarrollo de parches, llevaban mucho tiempo. No es razonable esperar que el software de código cerrado se mantenga al día sin amplias capacidades de prueba y que reciba constantemente faxes de los propios evaluadores cuando surgen problemas durante las pruebas. Las comunidades de desarrollo de código abierto tienen miles de evaluadores, mientras que el software de código cerrado tiene sólo unas pocas docenas. El software propietario carece de atractivo Los proveedores de software propietario, como Microsoft Corp., también han comenzado a investigar la posibilidad de añadir algo de poder social a su trabajo, con la esperanza de que esto mejore la seguridad de su software. Descubrieron que habían topado con algunos obstáculos que actualmente eran insuperables. Incluso los enfoques similares más generosos, como hacer que el código fuente sea visible para el público o hacer que nuevas versiones y parches estén disponibles para pruebas públicas, no logran el nivel de transparencia del que disfruta el software de código abierto. La razón es simple: la base de usuarios no tiene la misma inversión en el software en sí, el software es "software de otra persona" y no reciben la promesa de retornos futuros por parte del fabricante. El tiempo y la energía invertidos en el desarrollo y mejora del software pertenecen íntegramente al fabricante, lo que reduce en gran medida la motivación. La batalla entre lo visible y lo oculto La comunidad de desarrollo de código abierto se basa en una filosofía de seguridad de software que es muy diferente de la utilizada por el modelo de desarrollo de software propietario de código cerrado. Ocultar el código fuente puede cooperar con los fabricantes de software propietario para mantener los defectos durante un cierto período de tiempo, de modo que los programadores tengan tiempo suficiente para desarrollar parches. Esto mantiene la participación de mercado al crear una imagen segura, pero esto a menudo resulta en que un determinado defecto se vuelva rampante. en un período de tiempo determinado, y los usuarios no tienen idea de la situación peligrosa en la que se encuentran. El desarrollo de software de código abierto se beneficia de la transparencia, en lugar de endulzar posibles pérdidas de seguridad hasta que los parches estén disponibles y brinden a los usuarios las herramientas para protegerse. Estos beneficios no están completamente disponibles con el software del título.