La (in)seguridad del software

Hace unos meses leía en la web de Bruce Schneier un artículo en el que hablaba de la responsabilidad -o irresponsabilidad- de los generadores de software (por “generadores” me refiero a programadores, empresas de desarrollo, analistas, etc.) en la seguridad de la información. Bajo mi punto de vista, el software -en especial las aplicaciones- fallan. Fallan y mucho. Y demasiado. No únicamente desde el punto de vista de seguridad -que también-, sino incluso desde el punto de vista de la funcionalidad. Y lo peor, es que todos lo asumimos como algo habitual, como lo más normal del mundo, y como decía Schneier, incluso parcheamos nosotros mismos las aplicaciones (algo impensable con un coche, por ejemplo).

¿Por qué falla el software? Mi opinión es que en términos generales el software falla por cuatro grandes motivos; los comento, sin ningún orden particular:

La incultura de la seguridad
Muchos programadores (por programadores no me refiero únicamente a los que pican código, por supuesto) carecen de una cultura de seguridad a la hora de trabajar; simplemente no se tienen en cuenta los requisitos de seguridad de una aplicación, de un producto, ni en sus fases iniciales, ni en su implementación, ni en sus pruebas, ni en nada. El único objetivo es que funcione (hoy en día, ni siquiera que funcione rápido), que sea bonito (recuerden aquello de programa=algoritmo+marketing) y, en ocasiones, que sea tecnológicamente interesante. Poco más. ¿Seguridad? ¿Yesoqués?

El desconocimiento técnico
Incluso teniendo en cuenta la seguridad en el diseño o en la especificación de un programa, a la hora de implementarlo el desconocimiento técnico del programador hace que se cometan fallos garrafales en el código que, si no son corregidos a tiempo, acaban comprometiendo la seguridad de la información con la que tratan. No creo que valga la pena ahora hablar de errores habituales como buffer overflows o condiciones de carrera, pero alguna pregunta: ¿cuántos desarrolladores conocen el término TOCTTOU? ¿cómo se comprueban los datos que devuelve una orden del sistema? ¿qué alternativas a system() existen?

Las empresas de desarrollo
Una empresa siempre busca beneficios, y la seguridad es algo que no se ve. En ocasiones, los beneficios generados por un desarrollo seguro no se perciben desde la Dirección, por lo que en muchas empresas únicamente se busca la funcionalidad de las aplicaciones para obtener beneficios de las mismas. Dicho de otra forma, no se invierten los recursos necesarios en garantizar la calidad del software generado, únicamente se busca que la aplicación funcione y que se pueda liberar una nueva versión cuanto antes. Adicionalmente, una empresa de desarrollo no suele decir que no a nada. ¿Reprogramar la página web para poner una zona privada que enlaza con una base de datos externa? Para mañana. ¿Cifrado? Bah, no hace falta… Imaginad que necesitáramos un coche anfibio, con alas, reforzado, blindado y capaz de transportar 20 toneladas consumiendo menos de cinco litros. En un concesionario nos tomarían por locos, pero en una empresa de desarrollo nos dirían “Para mañana”. Ojo, un programa open source no suele tener la presión comercial detrás, y tampoco está libre de errores (le afectan por supuesto el resto de factores comentados aquí).

El error residual
Finalmente, incluso evitando todos los problemas anteriores, hay un porcentaje de errores que es inevitable; ese porcentaje es, a día de hoy -y de nuevo bajo mi punto de vista- demasiado alto en el desarrollo de software, y por supuesto debe reducirse a toda costa si queremos hablar de desarrollo seguro. Mientras no consigamos minimizar ese porcentaje de errores residuales, estaremos hablando de un problema serio, inimaginable en otros productos de uso masivo y diario.

¿Cómo evitar los problemas anteriores? No vamos a descubrir nada nuevo, obviamente, pero con algo tan sencillo como aplicar lo que ya sabemos, podríamos reducir, en un porcentaje muy significativo, el número de problemas de seguridad de las aplicaciones. En primer lugar, requerimos de formación e información; parece vergonzoso que en muchas facultades y escuelas de informática se hagan pocas referencias a la seguridad (si nuestra especialidad es Software, sustituyan el “pocas” por “ninguna”). Siendo así, ¿qué esperamos? Ni cultura de seguridad, ni conocimiento técnico, por supuesto. Y cuando hablamos de la dirección de la empresa, peor aún: la falta de cultura de la seguridad hace -no siempre, afortunadamente- que no se vean los beneficios que genera un desarrollo seguro. Si todos fuéramos conscientes de tales beneficios, otro gallo nos cantaría.

Finalmente, y hablando ya del error residual, creo que un factor decisivo para reducir el porcentaje de fallos es aplicar técnicas de ingeniería al desarrollo, algo que en la práctica se hace más bien poco (por mucho que en la carrera nos lo hayan explicado N veces). ¿Por qué? Eso sería seguramente material para muchos otros posts, más polémicos que este :)

Comments

  1. Completamente de acuerdo con todo el planteamiento, incluso con el que queda pendiente en el último apartado aunque es un tema a diseccionar con pinzas. A veces no entiendo como en las Facultades, los profesores no deben pasar por cursos de actualización cada X tiempo. Lo que enseñan respecto al software tiene que ir evolucionando con el tiempo.
    No se si conoces la herramienta de Microsoft para el “análisis del riesgo” en el diseño de aplicaciones denominada Application Threat Modeling. Encaja dentro de la filosofía de Microsoft que ha redefinido el ciclo del desarrollo del software, incorporando la seguridad ahora como un cimiento más (Han debido comprobar por experiencia propia que el “para mañana” no lleva a ningún sitio si se sacrifica la seguridad). Está presentada en el blog http://silverstr.ufies.org/blog/archives/001060.html y la herramienta es descargable en http://msdn.microsoft.com/en-us/security/aa570413.aspx
    Se ve que en este sentido, Microsoft a base de tortas (y pérdidas económicas seguramente), parece tenerlo algo más claro:
    “All security people know about Risk Assessment. If the end goal is to measure (loose definition) Risk, then why still call in Threat Modelling? Modelling the threats is a part of the goal (if you think about what ACE does its find the threats and vulns) but it’s not the end goal and it’s the end goal that customers care about, managing risk.”

    Por lo poco que he podido picotear y probar, creo que básicamente se trata de definir los “casos de uso” y los “casos de abuso” para saber identificar correcta y completamente los requisitos de seguridad.

  2. Antonio Villalón says

    Hola Javier

    De acuerdo contigo en cuanto al reciclaje en las facultades… no obstante, el reciclaje (reglado o no) debe ser un medio más, pero un medio complementado…por mucho reciclaje que hagamos, si no tenemos de base una cultura de seguridad, y nos limitamos a que los programas simplemente funcionen y sean bonitos, mal vamos. En fin, esperemos que algún día esto mejore :)

    En cuanto a la herramienta de Microsoft, no la conocía… le pegaré un vistazo :)

  3. Está claro que empezamos fallando de raiz, como bien comentais, mucha de la educación que se imparte en las universidades, es obsoleta, aparte de no tener ninguna importancia la seguridad para ellos, o por lo menos no se refleja en las materias.

    Creo que tanto la inseguridad del software como el cloud computing van a ser dos temas capitales en 2009. Por ejemplo, ISC2, ya dispone de una certifiación en la que se centra en el ciclo de vida del software ( http://www.isc2.org/csslp/default.aspx )

  4. Antonio Villalón says

    Muy interesante la certificación de ISC2 (no la conocía)… ya le estoy pegando un vistazo :)

  5. Coincido plenamente con vosotros en que, partiendo de la base de una mala formación (mala por escasa o por poco actualizada) los cimientos sobre los que se construye el software han de ser, por fuerza, inestables. Si a eso le sumamos las prisas en el desarrollo de software, debidas a plazos demasiado estrechos, sin margen de maniobra, donde lo único que importa es que funcione (o que parezca que funciona) una determinada aplicación, mal vamos.

    Personalmente, he visto cómo cualquier proyecto se desarrolla intentando cumplir con las especificaciones señaladas, y al final, si da tiempo, se va gastando en realizar pruebas (incluso las unitarias, que deberían haberse codificado junto a la propia aplicación), o en dar algún nivel más de seguridad a la aplicación. En lugar de constituir un refuerzo al armazón que sustenta al software (un endoesqueleto) fabricamos un exoesqueleto como el de los escarabajos o las chinches. Así, buscando un pequeño hueco, el eslabón más débil de la cadena, tenemos todo el sistema comprometido.

    En tanto los desarrollos sean así, mal vamos. Por eso me parece interesante que existan cursos para enseñar a programadores a desarrollar utilizando técnicas de seguridad, que deberían estar integradas o ir de la mano de la ingeniería del software. La ISC2 tiene muy buena pinta a ese respecto, a ver qué tal está.

    Un saludo.

  6. Antonio Villalón says

    Hola Miguel… muy bueno -y muy gráfico- el ejemplo del endoesqueleto y exoesqueleto. Te lo tomaré prestado :)
    La verdad es que siempre es de agradecer que existan cursos focalizados en la seguridad, en este caso en el desarrollo… lo malo es que estos cursos sigan siendo, a día de hoy, noticia, cuando la noticia (o lo sorprendente, de forma negativa) debería ser que un curso de programación NO incluyera aspectos de seguridad… Poco a poco :)

  7. Estoy de acuerdo con todos los comentarios.

    Por otra parte, cada vez que una empresa necesita realizar un desarrollo sw (llamémosle ‘aplicación’) para cubrir una necesidad recurriendo a un tercero pasa lo siguiente:

    – dpto. de informática contacta con su proveedor habitual u otro.
    – dpto. de informática pasa los requisitos funcionales a implementar.
    – proveedor habitual, empieza el proyecto.
    – ……. (aquí podemos poner todas las ‘etapas’ del proyecto: ustedes dijeron aquello, nosotros entendimos eso, hemos implementado esto …)
    – se entrega el producto y se pone en producción (si hay suerte).
    – llega la auditoría bienal LOPD (bueno, también en el mejor de los casos).
    – llegan los incumplimientos por no cumplir las medidas necesarias mínimas obligatorias, puesto que resulta que la aplicación maneja datos personales.

    Por no extenderme mucho, puesto que podría ser materia para otro post, lo que pasa si no se incorpora la función de la seguridad en el ciclo de vida del sw (o de cualquier proyecto TIC) es lo siguiente:

    – la empresa cliente se centra en la funcionalidad.
    – el proveedor ni se ajusta a la normativa en vigor ni informa al cliente que ‘eso’ le va a costar más puesto que tiene que cumplir ciertos requisitos de seguridad.

    ¿Cuantas empresas de desarrollo de software son conscientes que existe una disposición final en el nuevo reglamento de la LOPD que les afecta?

    Si no se cumple con lo mínimo que exije la ley, ¿cómo esperamos ir más allá?

    Un saludo.

  8. Nuevona-Reciengraduada says

    Hola, es muy interesante todo lo publicado por ustedes, y me interesa mucho saber como puedo especializarme en estos temas, ya que recién termine materias y efectivamente en la Universidad este tema, no es muy relevante, hice mis practicas con la Dijin e Interpol, y el tema de la seguridad me gusto mucho. agradezco sus opiniones para aprender.