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 la nube.

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 final les 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 reparar que 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 discusiones puntuales 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 en el 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 empresas no 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 interesa generar 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 podido desarrollar 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 de controles 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 años... ya saben en que terminó.

Parecería entonces que la discusión termina aquí, pero para ser justos con quienes se oponen a la afirmación que se debatió, yo diría que aplica si estamos considerando prácticas actuales de seguridad (i.e. traditional security + development = fail).

Propuesta de solución

Debemos atacar el problema de raíz si queremos aspirar a dar solución a las necesidades de seguridad en aplicaciones (sea en Cloud o en ambientes tradicionales). De los argumentos propuestos considero que los siguientes se relacionan con los orígenes del problema:
  • Conflicto de interés donde los responsables del desarrollo implementan controles y verifican que su SW no tiene vulnerabilidades.
  • Falta de involucramiento de otras áreas además de los responsables del desarrollo (ej. áreas de negocio; algunos problemas de seguridad se derivan de deficiencias en los procesos de negocio, no de los aplicativos).
  • Falta de recursos adecuados (en cantidad y calidad) para asegurar que se pueden implementar controles técnicos en aplicaciones que sean razonablemente efectivos (en desarrollos in-house, normalmente todo mundo piensa que todo está bien hasta que ocurre un incidente que es visible. En muchos casos pueden pasar meses antes de que alguien detecté que una vulnerabilidad ha sido explotada internamente por mucho tiempo)
La propuesta es la siguiente:
  • Aceptemos que implementar seguridad desde cero en aplicativos es muy complejo y adoptemos librerías de controles de seguridad que han sido probadas por miles de personas a lo largo de varios años.
  • Utilicemos plantillas probadas por otros para funciones que suelen implementarse con vulnerabilidades (ej. plantillas para solicitudes SQL que incluyan filtros estándares de entradas, rutinas para gestión de memoria dinámica con controles para evitar desbordamientos de memoria y memoria sin liberar cuando ya no es necesaria, etc.)
  • Dichos controles deberán implementarse de forma que soporten procesos de control alineados a requerimientos regulatorios y necesidades propias del negocio, para mitigar aquellos riesgos que la organización no está dispuesta a aceptar (i.e. se debe realizar un análisis de riesgos de los procesos de negocio involucrados; con esto se justifica la inversión en y aplicación de cualquier control de manera razonable).
Como dicen mis colegas angloparlantes, desde mi punto de vista: "this is as good as it gets"; no hay más. Estos puntos resuelven los problemas de origen:
  • El usar librerías externas mitiga conflictos de interés, y permite implementaciones razonablemente seguras para las empresas en general (a menos que sean al NSA). Además, reutilizar funcionalidad de librerías no implica mucho tiempo (en casi todos los casos será más rápido que invertir tiempo en desarrollar controles propios desde cero).
  • El diseñar aplicativos para reutilizar librerías de controles genéricos y plantillas de código, así como el alinearse a procesos de seguridad, facilita las auditorías y la revisión de cumplimiento regulatorio.
  • Generar un análisis de riesgos de los procesos de negocio involucra a todas las áreas y las vuelve corresponsables en la aceptación y mitigación de los riesgos resultantes.
  • Alinear la implementación de controles con un análisis de riesgo al negocio convierte en automático a los objetivos de seguridad en niveles de servicio requeridos.
Conclusiones
Debemos reconocer que lo mejor que se puede lograr en seguridad para aplicativos dista mucho de lo ideal (sobre todo si buscamos un enfoque preventivo) y que los controles a implementar dependerán de cada empresa (resultado del análisis de riesgos).

Sin embargo, es factible llegar a un nivel de seguridad razonable con resultados reproducibles si se aceptan algunos cambios de paradigmas.

En particular, uno debe entender las implicaciones del uso de librerías y plantillas de código desarrolladas por externos. Nuestra naturaleza como seres humanos nos indica que debemos desconfiar más en lo externo que en lo interno, pero un análisis objetivo y detallado de los diversos argumentos nos indicará en muchos casos (como en éste), que dicho temor es infundado, y que el uso de recursos externos también puede tener ventajas para la seguridad.


Escrito por Omar Alejandro Herrera Reyna en http://candadodigital.blogspot.com/2010/11/seguridad-en-el-desarrollo-de-software.html