Seguridad y uso de Frameworks

En esta ocasión resumiré un trabajo que presenté en la conferencia SATURN 2014 de arquitectura de software junto con mis colegas Rick Kazman y Jungwoo Ryoo. Rick Kazman es investigador del Software Engineering Institute y académico en la Universidad de Hawaii. Jungwoo Ryoo es investigador de la Universidad del estado de Pennsylvania y  experto en temas de seguridad. Cabe señalar que la conferencia SATURN, organizada por el SEI, está enfocada a los practicantes y que este trabajo fue muy bien recibido por dicha comunidad, por lo que considero que puede ser de interés para los lectores de esta columna.

Enfoque arquitectónico hacia la seguridad

La seguridad del software es una preocupación cada vez más importante para las organizaciones. Sin embargo, pocos arquitectos abordan este atributo de calidad de manera estratégica. Los arquitectos y desarrolladores frecuentemente ponen un énfasis mayor en satisfacer los requerimientos funcionales, y la seguridad usualmente es aplicada como un “parche” durante o después de que la aplicación ha sido desarrollada.

Desarrollar código enfocado a la seguridad es una tarea compleja y, por ello, frecuentemente se recurre a la adopción y uso de frameworks que se enfocan en atender distintas áreas de la seguridad como pueden ser el control de acceso, el cifrado y la validación de entradas entre otras.

Podemos identificar tres enfoques relativos a la adopción de frameworks como parte del diseño de la arquitectura para resolver la seguridad:

• No adopción: La seguridad no es considerada dentro del diseño de la arquitectura y solamente se codifican soluciones ad-hoc para tratar aspectos de seguridad.

• Adopción parcial: Se introducen frameworks de seguridad después del diseño inicial de la arquitectura.

• Adopción completa: La seguridad es considerada dentro del diseño inicial de la arquitectura y parte de las decisiones del diseño incluyen el uso de frameworks enfocados a la seguridad.

Caso de estudio

Con el fin de comprender las consecuencias de los tres enfoques descritos anteriormente, realizamos un estudio sobre tres distintos sistemas empresariales accesibles vía web:

• Sistema 1. Un sistema de administración de registros médicos de fuente abierta llamado OpenEMR [1]. Desarrollado en PHP y representa el enfoque de no adopción.

• Sistema 2. Un portal web desarrollado usando HTML y JSP. En un principio utilizaba un enfoque de no adopción y posteriormente se decidió agregar una solución comercial para mitigar riesgos de seguridad en el código, aplicando así un enfoque de adopción parcial. Nos referiremos a éste como “Sistema 2 Antes” y “Sistema 2 después”.

• Sistema 3. Una aplicación interna programada en Java por una empresa mexicana. Este sistema representa el enfoque de adopción completa. Utiliza Spring security [2] como framework primario de seguridad pero también utiliza el framework ZK [3] en la capa de presentación, que también brinda protección de ataques comunes en esta capa.

Estos sistemas fueron analizados utilizando la herramienta IBM AppScan que analiza alrededor de 33 tipos distintos de vulnerabilidades tales como inyección de SQL, negación de servicio o indexado de directorios. La herramienta genera un reporte de resultados indicando la cantidad de vulnerabilidades identificadas, agrupadas por severidad. El análisis se enfocó únicamente en los aspectos de software, por lo que se deshabilitó hardware de seguridad tal como firewalls.

Adicionalmente se realizó una entrevista a los arquitectos de los distintos sistemas para entender los enfoques de seguridad que siguieron. Estas entrevistas se basaron en la lista de 17 tácticas de seguridad que se muestra en la Figura 1. Para cada una de las tácticas se le preguntó al arquitecto si la había considerado y, en caso afirmativo, qué medidas había tomado al respecto.

Figura 1: Categorización de tácticas de seguridad.

Resultados

La tabla 1 presenta un resumen del resultado del análisis sobre los distintos sistemas.

Como se puede observar de la tabla, los enfoques de adopción parcial y completa tienen los mejores resultados ya que ninguno de estos sistemas exhibió vulnerabilidades de severidad alta. En el caso del sistema 2, llama la atención que al introducir un framework de seguridad se eliminaron por completo las vulnerabilidades de severidad alta, y las medianas se recortaron a la mitad.

Por otro lado podemos apreciar que, a excepción del sistema 3, en los demás casos  una parte de las tácticas fueron implementadas mediante programación ad-hoc, y no usando frameworks u otros mecanismos externos. Podemos observar una relación entre el esfuerzo que estimaron los arquitectos para satisfacer aspectos de seguridad y el número de tácticas implementadas de manera ad-hoc.

Como era de esperarse, el enfoque de adopción completa resultó ser el mejor ya que el sistema en que se usó, es decir el sistema 3, no tuvo vulnerabilidades de severidad alta, y el esfuerzo que el arquitecto estimó haber dedicado a atender aspectos de seguridad fue bajo en comparación con los demás sistemas, además de que este fue el sistema en el cual se implementó la mayor cantidad de tácticas.

Consideraciones

La muestra de sistemas que se usó para este estudio es muy pequeña y esto impide llegar a conclusiones definitivas. Sin embargo, y a pesar del tamaño de la muestra, los resultados obtenidos permiten emitir la recomendación siguiente: la seguridad es un atributo de calidad que no se debe dejar “para después” y es conveniente elegir frameworks como parte de las decisiones de diseño de la arquitectura.

El  uso de frameworks tiene sentido pues quien desarrolla una aplicación para un dominio particular generalmente no es un especialista en temas de seguridad. Por otro lado, intentar desarrollar código ad-hoc para satisfacer aspectos de seguridad consume recursos valiosos del proyecto que podrían más bien estar enfocados en resolver la problemática de negocio.

Las únicas dificultades asociadas con el uso de frameworks para manejar la seguridad son las posibles curvas de aprendizaje asociada con los frameworks, y la necesidad de mantener actualizados los frameworks para estar al día respecto a las nuevas amenazas que aparecen con el tiempo.

Es conveniente, además, atender la seguridad usando una combinación de software y hardware como, por ejemplo, cortafuegos.

Una recomendación adicional es que al diseñar la arquitectura de un sistema, conviene tomar el catálogo de tácticas mostrado en la figura 1 a manera de checklist para asegurarnos que estamos cubriendo las distintas tácticas de seguridad.

Conclusión

La seguridad es un aspecto de gran importancia en la mayoría de las aplicaciones y es por ello que se le debe dar una consideración primordial como parte del diseño de la arquitectura. El considerar la seguridad desde el principio y usar frameworks para soportarla puede dar excelentes resultados.

Aprovecho este espacio para comentarles que estamos buscando más casos de estudio por lo cual si están interesados en que alguna de sus aplicaciones empresariales forme parte de este estudio no duden en contactarme en hcm@xanum.uam.mx. Los resultados del análisis y los datos de su organización serán confidenciales.

En la http://goo.gl/cZUIi5 pueden encontrar un video de la presentación de este trabajo realizada en SATURN 2014.

En http://goo.gl/plbwrJ pueden encontrar una lista de frameworks de seguridad (en constante evolución).

Referencias

1. Bass, Clements y Kazman, “Software Architecture in Practice”, 3a Edición, Addison-Wesley Professional, 2012.