Seguridad Informatica

Seguridad en el desarrollo de software

Recientemente tuvimos una discusión interesante en los foros de la "Cloud Security Alliance" (CSA) sobre el tema de seguridad en los aplicativos.

Al principio el tema propuesto no había generado mucha polémica y la gente se limitaba a repetir recetas tradicionales de seguridad para responder a la pregunta de cómo debemos proteger los aplicativos en lanube.

Pero bastó con que uno de los compañeros colocará un retador mensaje que atentara contra las más arraigadas prácticas para que ardiera Troya. El mensaje era de una sola línea: "Security + Development = Fail".

La oleada de respuestas no se hizo esperar, tanto a favor como en contra. A continuación muestro una reflexión sobre varios de los argumentos expuestos en este debate; al finalles comento sobre mi postura dentro del debate.

Argumentos en contra
Entre los argumentos más importantes que se presentaron en contra, se incluyen:
La alta incidencia de vulnerabilidades en aplicativos.
La falta de confianza en controles externos (en particular en esquemas de nube).
La necesidad de integrar los mecanismos de seguridad como un proceso.
El hecho de que sale más caro repararque prevenir.
La necesidad de sensibilizar y capacitar más a los programadores.
La necesidad de responsabilizar a todos los involucrados en el ciclo de desarrollo (no sólo a los programadores).
Sólo porque sea difícil no significa que debamos darnos por vencidos; sin ser perfecta se puede llegar a un nivel razonable de seguridad.
Y por supuesto algunos de los mensajes derivaron en discusionespuntuales sobre experiencias en la inclusión de la seguridad en el ciclo de vida de desarrollo de software (SDLC por sus siglas en inglés), se mencionaron y se rindieron los tributos correspondientes a OWASP y similares, y se recalcó la importancia de la seguridad en software como servicio.

Argumentos a favor
Aquí se mencionaron los siguientes argumentos:
Tanto tiempo incluyendo seguridad enel SDLC no ha dado los resultados esperados.
Los programadores entienden la seguridad e implementan controles de diferente manera.
Existe un conflicto de interés en el que caen los desarrolladores (les pagan por entregar algo que funcione y rápido, y deben de aplicar controles que limitan esto, mitigando riesgos que ellos mismos generan).
Los objetivos de negocio de la mayoría de las empresasno incluyen, por lo general, desarrollar software seguro.
Desarrollar software seguro es extremadamente difícil y demanda recursos que pocas empresas poseen.
De este lado se hizo énfasis en la falta de resultados y la imposibilidad de lograr el objetivo de generar software seguro, con un balance adecuado de costo beneficio adecuado (en otras palabras, a la mayoría de las empresas no les interesagenerar software seguro).



Análisis
Creo que en el fondo, ambas posturas tienen algo de razón, si bien me tiendo a inclinar un poco en favor de quienes apoyan la frase que desató la discusión.

La razón es la siguiente: el argumento de los resultados es demoledor. Prácticas, metodologías , campañas y todo tipo de artilugios van y vienen, y no hay una sola empresa que haya podidodesarrollar una aplicación de un tamaño razonable ("Hola mundo" no cuenta) que no haya tenido vulnerabilidades, o cuyos controles hayan sido 100% efectivos.

Peor aún, díganme si conocen alguna empresa que se atreva a asegurar que los controles de seguridad de software (acceso, criptográficos, anomalías, registro de eventos, filtrado de entradas y salidas, etc.) son más efectivos que las librerías decontroles abiertas o comerciales disponibles (piensen por ejemplo en OpenSSL).

A mi mente solo vienen algunas organizaciones como la NSA que quizás puedan argumentar que cuentan con los recursos y motivación suficiente para hacer esto; prácticamente todas ellas ligadas con gobiernos de países poderosos. Recordemos que Oracle sí se atrevió con su campaña "Oracle9i. Unbreakable" hace algunos...