La seguridad de las aplicaciones suele enfocarse como un añadido al final del proceso de desarrollo. Normalmente este «añadido» suele materializarse en la realización de algún tipo de tests de seguridad (pen testing, análisis estáticos y dinámicos del código fuente…), resultado de los cuales se identifican y corrigen las vulnerabilidades detectadas en el producto software.
Este modelo, esencialmete reactivo, basado en la aplicación de parches correctivos, supone una importante limitación en el nivel de seguridad que pueden alcanzar las aplicaciones desarrolladas, ya que, como hemos mencionado en alguna otra ocasión, la máxima seguridad del producto se alcanza cuando esta seguridad está embebida en el diseño, habiendo sido considerada de manera intrínseca a lo largo de todo el ciclo de vida, y especialmente desde las fases iniciales de definición y diseño técnico.
En este artículo vamos a analizar brevemente algunas de las causas que frecuentemente limitan la capacidad de las organziaciones para desarrollar aplicaciones seguras y plantearemos algunas soluciones, principalmente en el terreno organizativo. El orden en que enumeraremos estas causas no implica que alguna causa sea más relevante que otra.
Creencias sobre el impacto negativo de las medidas de seguridad
Existe una creencia (más o menos justificada) por parte de las áreas de negocio, proyectos y desarrollo de aplicaciones de que las medidas de seguridad de aplicaciones impactan negativamente en la usabilidad del producto final y la consiguiente aceptación por parte de los usuarios. Al mismo tiempo, las medidas de seguridad de las aplicaciones suelen ser consideradas con cierta precaución dado que suelen aumentar la complejidad del desarrollo y causan un incremento en los costes y el tiempo de desarrollo.
Efecto Silo entre áreas de desarrollo y de seguridad de aplicaciones
Normalmente, existe un silo o separación entre los equipos que desarrollan las aplicaciones y aquellos encargados de la seguridad. Por un lado, los desarrolladores suelen estar más focalizados en la entrega del software dentro de los plazos previstos; por otro, los desarrolladores no suelen tener formación en cuestiones relacionadas con las vulnerabilidades de seguridad y las prácticas de programación seguras. La propia metodología de desarrollo empleada por muchas empresas, hace de hecho que la seguridad sea considerada como «la responsabilidad de otros». En general, se evidencia una falta de comunicación y a veces incluso suspicacias entre ambos «bandos».
Limitaciones de los equipos responsables de la seguridad
Los equipos encargados de la seguridad de aplicaciones no suelen tener una visión clara del contexto y la relevancia para las aplicaciones y a veces actúan no como aliados de los equipos de proyecto, sino más bien como «estrictos jueces» garantes de la pureza de las prácticas de seguridad; por otro lado, en muchas ocasiones los encargados de la seguridad no son expertos en las técnicas de desarrollo empleadas y tienen dificultades para corregir de manera efectiva las vulnrabilidades identificadas. En algunas ocacsiones, incluso, cuando las medidas correctoras recomendadas causan otros errores de la aplicación, la reputación de estos equipos se puede ver afectada y su aislamiento en los proyectos incrementado.
Incompatibilidad de las prácticas de seguridad y las metodologías ágiles
Existe otra creencia de que las prácticas de seguridad de aplicaciones (pen testing, verificaciones de código, etc…) no escalan bien ni son compatibles con las metodologías ágiles. De hecho, desde una comprensión sesgada de lo que las metodologías ágiles son, algunos piensan que las prácticas de seguridad forman parte de las fases «prescindibles».
Inversión en seguridad como medida reactiva
La realidad demuestra que en muchas ocasiones la inversión en seguridad de las aplicaciones viene originada principalmente por la presión regulatoria (leyes de protección de datos, normativa bancaria o sectorial…) o en el peor de los casos por la urgente necesidad de corregir las consecuencias de una brecha de seguridad sufrida por la organización. En este sentido, a consecuencia del frecuente impacto mediático que estas brechas de seguridad tienen en los medios, se observa una creciente sensibilización por parte de los directivos de las compañías sobre el posible impacto en el negocio de estas brechas de seguridad. Sea como sea, la inversión se origina y se orienta hacia una respuesta reactiva del problema que deriva en un enfoque centrado en la corrección de vulnerabilidades y no tanto en un enfoque basado en análisis y gestión de riesgos.
Algunas posibles mejoras
A continuación se plantean algunas posibles medidas (principalmente de tipo organizativo) que entendemos benefician el desarrollo de aplicaciones más seguras:
- Crear equipos mixtos de desarrolladores, expertos en seguridad y operadores y administradores de sistemas, con el objetivo de que colaboren entre si de manera continuada a lo largo de todo el ciclo de desarrollo, con el objetivo de que la seguridad esté embebida en los productos software «desde dentro». Este enfoque, conocido como SecDevOps, supone una revolución respecto de la forma en que los departamentos de IT estaban tradicionalmente organizados y supone la ruptura de los mencionados silos y la idea de que la segruidad es un asunto «de otros».
- Desarrollar planes de formación y actividades de concienciación. En este sentido, es crucial que los equipos de desarrollo sean formados en practicas de programación segura y conozcan la naturleza de las principales vulnerabilidades; por otro lado, es necesaria la formación de los expertos de seguridad sobre las plataformas y los métodos de desarrollo empelados.
- Abordar el proceso de gestión de vulnerabilidades de una manera más proactiva, centrándose en la identificación de las causas raíz de los problemas y usando las lecciones aprendidas para una mejora continua del proceso; por otro lado, conviene abordar una estrategia que conbine la gestión de detección y corrección de vulnerabildiades con otras prácticas mas orientadas al análisis y gestión de riesgos en las fases de diseño y desarrollo.
En cuanto a aspectos metodológicos/técnicos:
Incorporación de prácticas de desarrollo seguro de aplicaciones en las metodologías ágiles para asegurarse de que la seguridad se concible como una característica intrínseca del diseño del producto software.
Un fuerte abrazo, gracias por la atención prestada y hasta pronto.
Negocios bajo control 