Seguridad de Software de Código Abierto

La seguridad de software de código abierto es la medida para asegurarse o garantizar el estar libre de peligros o riesgos inherentes a un sistema de código abierto.

Software de código abierto contra algoritmos libres

Un proyecto de software es una implementación de un algoritmo en general. Aunque estas implementaciones sólo pueden ser probadas, y las pruebas sólo pueden demostrar la presencia de errores (y no la ausencia de estos), los algoritmos pueden ser probados correctamente. En el cifrado de clave secreta, una de las premisas es que el algoritmo debe ser conocido y sólo una pequeña parte de la información debe mantenerse en secreto: La clave secreta. Es decir, para que un cifrado se considere seguro, se debe de demostrar que el algoritmo es correcto y la prueba de esto debe estar disponible para cualquier persona que quiera utilizar el cifrado. Por lo tanto, en seguridad computacional, hay un consenso de que los algoritmos deben estar abiertos, sin embargo hay un debate sobre si sus implementaciones deben de ser de código abierto (público) o software propietario (secreto).

Debate de la implementación

El esfuerzo de probar (auditar) una implementación se reduce considerablemente, si se centra en la verificación que corresponde al algoritmo correcto (probado previamente). Teniendo en cuenta que el que realiza las pruebas (auditor) tiene acceso al código fuente, esto sólo se puede hacer si el software es de código abierto o software propietario.

Es muy importante entender que la auditoría de software depende del acceso al código fuente. Debido a eso, una nueva auditoría de un software propietario depende de lo que desee el propietario del software, mientras que la auditoría en el software de código abierto se puede hacer en cualquier momento por cualquier persona que lo desee.

Esta preocupación se ha vuelto más y más severa ya que se dejan puertas traseras, en consecuencia, zonas de seguridad de software bien establecidas han sido reveladas. Además de esto, hay un debate en curso sobre si el software de código abierto aumenta la seguridad del software, o afecta a la misma, pero se ha vuelto inútil. A pesar de que algunos de los argumentos de ambos lados son subjetivos y no hay relación entre el número de vulnerabilidades en una aplicación y como es que si es código abierto/propiedad influye, cada uno de ellos puede contener puertas traseras. Sin embargo, sólo el software de código abierto puede ser auditado libremente y por lo tanto, el software propietario debe considerarse inherentemente inseguro

Beneficios de la seguridad de código abierto

Más personas pueden inspeccionar el código fuente para encontrar y solucionar una posible vulnerabilidad. Esto puede llevar tanto al descubrimiento de vulnerabilidad de seguridad intencional rápidamente como a la prevención de vulnerabilidades intencionales (puertas traseras) localizadas en el código, el cual es puesto allí por los propios desarrolladores.
El Software propietario obliga al usuario a aceptar el nivel de seguridad que el proveedor de software está dispuesto a ofrecer y a aceptar la cantidad de "parches" y actualizaciones disponibles.^[1]
El usuario final del código abierto tiene la capacidad de cambiar y modificar la fuente para implementar cualquier "característica" extra de seguridad que quiera para un uso específico, que puede extenderse hasta el nivel de kernel si así lo desea.
Se asume que cualquier compilador que es utilizado crea código confiable, pero se ha demostrado por Ken Thompson que un compilador puede ser subvertido utilizando un Thompson hack para crear ejecutables defectuosos que se producen involuntariamente por un desarrollador sin malas intenciones.^[2] Con el acceso al código fuente para el compilador, el desarrollador tiene por lo menos la capacidad de descubrir si hay alguna mala intención.
- David A. Wheeler demuestra que la existencia de dos diferentes compiladores de auto-compilación de código abierto (que deben de ser capaz de compilar entre sí) se puede utilizar para establecer un binario para uno de ellos que es conocido por no ser subvertido por el Thompson hack.^[3]
El principio de Kerckhoffs se basa en la idea de que un enemigo puede robar un sistema militar seguro, pero no es capaz de poner en peligro la información. Sus ideas fueron la base para muchas de las prácticas modernas de seguridad , y dice que la seguridad por obscuridad son malas prácticas.^[4]

Esquemas de seguridad de código abierto

Los atacantes pueden encontrar vulnerabilidades más fáciles con el código fuente.
Simplemente, al crear un código fuente no se garantiza que exista una revisión. Un buen ejemplo de que esto ocurre fue cuando Marcus Ranum, un experto en el diseño de sistemas de seguridad y aplicaciones, lanzó su primer kit de herramientas firewall públicas. Hubo una época en la que había más de 2,000 sitios que usaban este kit de herramientas, pero solo 10 personas dieron algún comentario de retroalimentación o algún parche.^[5]
Tener una gran cantidad de ojos revisando el código puede "hacer que un usuario tenga una falsa sensación de seguridad".^[6] Tener muchos usuarios mirando el código fuente no garantiza que los problemas de seguridad se vayan a encontrar y arreglar.

Métricas y modelos

Hay una gran variedad de modelos y métricas para medir la seguridad de un sistema. Estos son algunos métodos que pueden utilizarse para medir la seguridad de los sistemas de software.

Número de días entre vulnerabilidades

Se discute que un sistema es más vulnerable después de que se descubre una vulnerabilidad potencial, pero antes de que se ponga un parche. Al medir el número de días entre la vulnerabilidad, cuando la vulnerabilidad es arreglada, se puede determinar una base en la seguridad del sistema. Hay algunas advertencias en este enfoque: no toda vulnerabilidad es igual de mala; arreglar muchos errores rápidamente puede ser peor que buscar y arreglar solamente unos pocos y que se tome un poco más de tiempo en cada uno de ellos, tomando en cuenta el sistema operativo o la efectividad del parche.^[2]

Proceso de Poisson

El proceso de Poisson se puede utilizar para medir las tasa de cambio con la que diferentes personas encuentran fallos de seguridad entre el software de código abierto y cerrado. El proceso puede ser dividido entre el número de voluntarios N_v y revisores pagados N_p. Las tasas de cambio con la que los voluntarios encuentran un defecto se mide por λ_v y la tasa con la que revisores pagados se encuentran un defecto se mide por λ_p. El tiempo que se espera para que un grupo de voluntarios encuentre un error es 1/(N_v λ_v) y el tiempo que se espera para que un grupo pagado encuentre un defecto es 1/(N_p λ_p).^[2]

Modelo estrella

Mediante la comparación de una gran variedad de códigos abiertos y cerrados con un sistema de estrellas, se puede analizar la seguridad del proyecto, similar a la empresa Morningstar, Inc. la cual valora los fondos de inversión. Con un conjunto de datos suficientemente grande, las estadísticas se podrían utilizar para medir la eficacia global de un grupo sobre otro. Un ejemplo de como funciona el sistema es el siguiente:^[7]

1 Estrella: Muchas vulnerabilidades de seguridad.
2 Estrellas: Problemas de fiabilidad.
3 Estrellas: Sigue las mejores prácticas de seguridad.
4 Estrellas: Proceso documentado de desarrollo de seguro.
5 Estrellas: Pase de revisión de seguridad independiente.

Escáner Coverity

Coverity en colaboración con la Universidad de Stanford ha establecido un nuevo punto de referencia para la calidad y seguridad del código abierto. El desarrollo se completa a través de un contrato con el Departamento de Seguridad Nacional. Ellos están utilizando las innovaciones en la detección automática de defectos para identificar los tipos de errores críticos encontrados en el software.^[8] El nivel de calidad y de seguridad se mide en los escalones. Los escalones no tienen un sentido definitivo, y pueden cambiar a medida que Coverity lanza sus nuevas herramientas. Los escalones se basan en el progreso de desarrollo de parches encontrados en los resultados del análisis de Coverity y con el grado de colaboración, en conjunto con Coverity.^[9] Comienzan con el escalón 0 y actualmente llega al escalón 2.

Escalón 0

El proyecto ha sido analizado por la infraestructura de escaneo de Coverity, pero no hay representantes del software de código abierto que se hayan presentado a revisar los resultados.^[9]

Escalón 1

En el escalón 1, existe colaboración entre Coverity y el equipo de desarrollo. El software se analiza con un subconjunto de funciones de escaneado para evitar que el equipo de desarrollo sea abrumado.^[9]

Escalón 2

Hay 11 proyectos que se han analizado y actualizado a la condición de escalón 2 al llegar a no tener ningún defecto en el primer año de exploración. Estos proyectos incluyen: AMANDA, ntp, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, y tcl.^[9]

Referencias

↑ Cowan, C. (January 2003). Software Security for Open-Source Systems. IEEE Security & Privacy, 38–45. Retrieved 5 May 2008, from IEEE Computer Society Digital Library.
↑ ^a ^b ^c Witten, B., Landwehr, C., & Caloyannides, M. (2001, September/October). Does Open Source Improve System Security? IEEE Software , 57–61. Retrieved 5 May 2008, from Computer Database.
↑ Wheeler, David A. Fully Countering Trusting Trust through Diverse Double-Compiling.
↑ Hoepman, J.-H., & Jacobs, B. (2007). Increased Security Through Open Source. Communications of the ACM , 50 (1), 79–83. Retrieved 5 May 2008, from ACM Digital Library.
↑ Lawton, G. (March 2002). Open Source Security: Opportunity or Oxymoron? Computer , 18–21. Retrieved 5 May 2008, from IEEE Computer Society Digital Library.
↑ Hansen, M., Köhntopp, K., & Pfitzmann, A. (2002). The Open Source approach – opportunities and limitations with respect to security and privacy. Computers & Security , 21 (5), 461–471. Retrieved 5 May 2008, from Computer Database.
↑ Peterson, G. (6 May 2008). Stalking the right software security metric. Retrieved 18 May 2008, from Raindrop: http://1raindrop.typepad.com/1_raindrop/security_metrics/index.html
↑ Coverity. (n.d.). Accelerating Open Source Quality. Retrieved 18 May 2008, from Scan.Coverity.com: http://scan.coverity.com/index.html Archivado el 5 de marzo de 2016 en Wayback Machine.
↑ ^a ^b ^c ^d Coverity. (n.d.). Scan Ladder FAQ. Retrieved 18 May 2008, from Scan.Coverity.com: http://scan.coverity.com/ladder.html Archivado el 6 de marzo de 2016 en Wayback Machine.

Enlaces externos

Bruce Schneier: Open Source and Security Crypto-Gram Newsletter, 15 September 1999

Datos: Q7096421

[1] Cowan, C. (January 2003). Software Security for Open-Source Systems. IEEE Security & Privacy, 38–45. Retrieved 5 May 2008, from IEEE Computer Society Digital Library.

[Witten-2] Witten, B., Landwehr, C., & Caloyannides, M. (2001, September/October). Does Open Source Improve System Security? IEEE Software , 57–61. Retrieved 5 May 2008, from Computer Database.

[Wheeler-3] Wheeler, David A. Fully Countering Trusting Trust through Diverse Double-Compiling.

[4] Hoepman, J.-H., & Jacobs, B. (2007). Increased Security Through Open Source. Communications of the ACM , 50 (1), 79–83. Retrieved 5 May 2008, from ACM Digital Library.

[5] Lawton, G. (March 2002). Open Source Security: Opportunity or Oxymoron? Computer , 18–21. Retrieved 5 May 2008, from IEEE Computer Society Digital Library.

[6] Hansen, M., Köhntopp, K., & Pfitzmann, A. (2002). The Open Source approach – opportunities and limitations with respect to security and privacy. Computers & Security , 21 (5), 461–471. Retrieved 5 May 2008, from Computer Database.

[7] Peterson, G. (6 May 2008). Stalking the right software security metric. Retrieved 18 May 2008, from Raindrop: http://1raindrop.typepad.com/1_raindrop/security_metrics/index.html

[CoverityIndex-8] Coverity. (n.d.). Accelerating Open Source Quality. Retrieved 18 May 2008, from Scan.Coverity.com: http://scan.coverity.com/index.html Archivado el 5 de marzo de 2016 en Wayback Machine.

[CoverityLadder-9] Coverity. (n.d.). Scan Ladder FAQ. Retrieved 18 May 2008, from Scan.Coverity.com: http://scan.coverity.com/ladder.html Archivado el 6 de marzo de 2016 en Wayback Machine.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]