El software abierto y la seguridad

82
Perspectiva Empresarial
El software abierto
y la seguridad
EL HECHO DE ELEGIR UN SISTEMA DE CÓDIGO ABIERTO NO DEBE RELAJAR NUESTRA
POLÍTICA DE SEGURIDAD NI HACERNOS SENTIR INVULNERABLES A LOS ATAQUES
Carlos
de Nova
tienen la oportunidad de estudiar el
disponible, aspecto fundamental
software para determinar sus
cuando hablamos de añadir nuevas
vulnerabilidades.
funcionalidades, los atacantes no
Esta parece ser la clase de cuestión
INGENIERO DE
DESARROLLO
Zitralia
necesitan del código fuente para
en la que parece posible dar una
encontrar y explotar agujeros de
respuesta clara sobre la base de
seguridad.
modelos aceptados de estabilidad del
Por ello es importante distinguir
software o datos empíricos sobre
entre actos destructivos y
vulnerabilidades reportadas, o mejor
constructivos. En realidad siempre es
aún sobre ambos.
más fácil destruir algo que construirlo.
Antecedentes
En el mundo del software también es
mucho más fácil encontrar una
T
vulnerabilidad y explotarla que añadir
radicionalmente se ha
asumido siempre que el
modelo de código abierto
permitía disponer de un código de
mayor calidad y más seguro, debido a
que la propia comunidad era la
encargada de mantener el código
fuente. Ante esto, los defensores del
modelo de código fuente propietario
respondían que el libre acceso al
Para un atacante el no
disponer del código fuente
no supone ninguna
dificultad para buscar fallos
en la seguridad del mismo
Los atacantes tienen la ventaja
sobre los defensores debido a esta
diferencia. Los desarrolladores de
software intentan no tener errores de
seguridad relevantes en todo su
código, mientras que los atacantes
sólo deben encontrar uno que puedan
centran básicamente en que sus
de agujeros en la seguridad del
Profundizando en el asunto
programas funcionen, los atacantes no
necesitan que funcione, sólo encontrar
En la comunidad de criptólogos en
particular, ha sido una práctica
existente.
explotar. Los desarrolladores se
código fuente facilitaba la localización
software.
una nueva funcionalidad a lo ya
Sin embargo la cuestión va mucho
debilidades en el mismo. Esto hace
habitual desde el siglo diecinueve, que
más allá de estos planteamientos
que el esfuerzo necesario para atacar
el oponente conociera el diseño de su
contrapuestos. Se suele argumentar
un programa sea sensiblemente
sistema, de tal forma que el único
que un sistema con el modelo de
inferior al de modificarlo.
camino posible para mantener el
código cerrado es más seguro puesto
secreto, era manteniendo a salvo el
que ofrece menos información al
tanto en entornos de código abierto
conocimiento de una variable
atacante y por tanto es más
como de código cerrado usan dos
temporal, la clave. Por otro lado los
complicado el encontrar
tipos de técnicas que podríamos
opositores al software abierto
vulnerabilidades. La debilidad de este
llamar estáticas y dinámicas. En las
argumentan que si el software es
argumento reside en que a pesar de
estáticas se inspecciona el código
abierto, los potenciales atacantes
que el código fuente no esté
fuente o el código máquina, y en las
nº 12 julio 2007
De forma general los atacantes
83
Perspectiva Empresarial
dinámicas se ejecuta el software
testeando sobre los diferentes
comportamientos que éste tiene ante
el envío de datos (normalmente
malformados). Ante el uso de las
técnicas dinámicas, no hay ninguna
diferencia entre el software de código
abierto y cerrado, ya que en ningún
momento se está inspeccionando el
código. En el caso de las técnicas
estáticas, tampoco existe diferencia
para el atacante, ya que no busca
implementar nuevas funcionalidades,
por lo que no necesita el código
fuente para buscar los patrones
potencialmente inseguros. Este punto
es importante ya que para un
atacante el no disponer del código
fuente no supone ninguna dificultad
para buscar fallos en la seguridad del
mismo.
Entonces nos podríamos preguntar
cuál es la importancia real de
distribuir o no el código. La respuesta
es que mientras que un desarrollador
no necesita el código fuente para
encontrar vulnerabilidades, sí las
necesita para poder eliminarlas una
“demandar código de fuente abierta
puede mirar el código, sino y más
vez encontradas.
para cualquier asunto relacionado con
importante, porque este modelo
la seguridad” [Schneier 1999].
fuerza a la gente a escribir código
tengamos software cerrado no nos
Vincent Rijmen, uno de los
más claro y adherido a estándares. Lo
protege en absoluto frente a las
desarrolladores del algoritmo de
que facilita las auditorías de
Como vemos, el hecho de que
seguridad”. [Rijmen 2000].
vulnerabilidades software.
Whitfield Diffie es el coinventor
de la criptografía basada en clave
Lo que dicen los expertos
En general la opinión de los
expertos sobre el tema es que la
naturaleza del software abierto o
cerrado no tiene un impacto directo
sobre la seguridad del mismo, si bien
el software de código abierto facilita
en gran medida el potencial de poder
Es mucho más fácil
encontrar una vulnerabilidad
y explotarla que añadir una
nueva funcionalidad a lo ya
existente
ser más seguro que su contraparte de
pública (base de toda la seguridad en
Internet); es ingeniero senior y jefe
de seguridad en Sun Microsystems.
En su artículo de 2003, “Risky
business: Keeping security a secret”,
dice que el argumento de los
vendedores de código cerrado sobre
que su software es más seguro
porque es secreto, es un sinsentido.
“Simplemente es irreal depender del
código cerrado, pero que por el hecho
secreto para mantener la seguridad
de ser software abierto no es una
encriptación AES (Advanced
en el software. Quizás sea posible
garantía de seguridad en sí misma.
Encryption Standard), cree que la
mantener fuera de circulación cómo
naturaleza de código abierto de Linux
un software funciona exactamente,
criptógrafo y experto en seguridad
facilita el hecho de encontrar y fijar
pero no puedes prevenir que tu
informática. Argumenta que los
las vulnerabilidades de seguridad. ”No
código sea inspeccionado mediante
ingenieros inteligentes deberían
sólo porque haya más gente que
ingeniería inversa.”
Bruce Schneier es un reputado
nº 12 julio 2007
84
Perspectiva Empresarial
John Viega en su artículo "The
Myth of Open Source Security"
también nos aporta lo siguiente: “Los
proyectos de código abierto pueden
ser más seguros que sus
contrapuestos de código cerrado. De
cualquier forma las cosas que pueden
hacer que un software de código
abierto sea más seguro -disponibilidad
de código fuente, y el mayor número
de personas buscando y fijando
agujeros de seguridad- pueden hacer
por el que un atacante pueda
Mientras que un
desarrollador no necesita el
código fuente para
encontrar vulnerabilidades,
sí las necesita para poder
eliminarlas
caer a la gente en una falsa sensación
[Schneider 2000].
Peter G. Neumann también
afirma que el código abierto no es
seguro por sí mismo ni por su
naturaleza, a pesar del potencial que
tiene para serlo. [Neumann 2000].
Brian Witten, Carl Landwehr y
Michael Caloyannides [Witten
2001] publicaron un artículo
concluyendo que la disponibilidad del
código fuente trabaja en favor de la
de seguridad.
Michael H. Warfield en "Musings
vulnerar nuestros sistemas”
seguridad de los sistemas. ”Nosotros
razones para creer que muchos ojos
llegamos a cuatro conclusiones en
on open source security" es muy
inspeccionando el código de fuente
este asunto. Primero, el acceso al
positivo sobre el impacto del software
abierta permita tener éxito en
código fuente permite a los usuarios
de código abierto sobre la seguridad.
identificar los errores que
mejorar la seguridad de los sistemas,
Por contra, Fred Schneider no cree
comprometen la seguridad de un
si tienen la capacidad y los recursos
que el software de código abierto
sistema y que esos errores de
para hacerlo. Segundo, tests
ayude a la seguridad, “no hay
codificación no son el origen principal
limitados indican que en algunos
casos los ciclos de vida del software
de código abierto son menos
vulnerables a fallos no intencionados.
Tercero, un estudio sobre tres
sistemas operativos indica que un
sistema operativo de código abierto
sufre menos vulnerabilidades
conocidas sin arreglar en un período
de 12 meses que los otros dos
sistemas propietarios. Por último, los
modelos de desarrollo de sistemas
cerrados o propietarios Last, incentiva
el desarrollo de sistemas menos
seguros debido a que son más
rentables que sistemas más seguros.”
Conclusiones
Como podemos ver el hecho de
elegir un sistema de código abierto
no debe relajar nuestra política de
seguridad ni hacernos sentir
invulnerables a los ataques. Tampoco
podemos descartar estos sistemas por
considerarlos inseguros por el mero
hecho de ser software de código
abierto. Al igual que en los entornos
de software cerrado debemos
proteger nuestros sistemas y nuestros
datos con la misma eficiencia y
tenacidad.
nº 12 julio 2007