Opinión
Ciberseguridad, COVID-19 y piscinas
A día de hoy si hablamos de COVID-19, piscinas y Ciberseguridad, parece que estamos hablando de temas de máxima actualidad pero inconexos entre sí. Sin embargo, el ámbito de la Ciberseguridad ilustra una realidad que se manifiesta en multitud de situaciones que cada vez preocupan más a organizaciones y ciudadanos.
El desarrollo de un software de forma rápida (time to market) que permita cubrir una necesidad acuciante –en este caso el acceso de forma organizada a un recinto en base a un aforo concreto- implica asumir muchos riesgos. Una mala gestión puede llevar a exponer datos de carácter personal de forma inadecuada, con todos los peligros que esto conlleva ¿Qué ocurre si alguien puede saber a la hora exacta en que voy a estar en la piscina en vez de en mi casa?
Es por tanto evidente, que todas las aplicaciones son críticas para la seguridad de la compañías y de las personas que las utilizan, tanto por el rol que tienen estas en las organizaciones como por los datos que albergan (información personal sensible). Así, las mayores amenazas alrededor de las aplicaciones y los procesos necesarios para minimizar el riesgo de las mismas son acotadas.
El go to market y los presupuestos ajustados, origen del problema
El desarrollo de aplicaciones es un proceso complejo y que debería ser correctamente estructurado siguiendo las mejoras prácticas definidas en la Ingeniería del Software. Pero en muchas ocasiones, no se siguen todos estos procesos definidos, por falta de tiempo (por el go to market, motivos comerciales o adaptaciones a normas, por ejemplo), y otras muchas veces por presupuestos escuetos que no permiten realizar los procesos esenciales para construir software de una manera profesional.
Es usual ver grandes empresas con aplicaciones normalmente no críticas para su negocio, con un nivel de calidad bajo. Por tanto, este es un problema que tiene una afectación extensa, y no solo restringido a organizaciones sin recursos.
Cuando no hay tiempo o presupuesto, la seguridad pasa a segundo plano
Uno de los aspectos más afectados por los tiempos de desarrollo y presupuestos ajustados es la seguridad. Muchos proyectos que parten de premisas como: “Esta aplicación no contiene información sensible o no vende nada”, para que alguien decida que por tanto, no es necesario incluir seguridad. Obviamente, esta actitud es un claro error ya que la seguridad, como el resto de aspectos del desarrollo, debe adaptarse a las necesidades del proyecto, lo cual no implica eliminarla.
Toda aplicación, crítica o no para la organización, debe partir desde una base sólida y segura que le permita avanzar en el proyecto sin retrocesos y estar protegida antes ataques que, en el mejor caso, manchen la reputación de esa compañía.
La seguridad, un cambio de cultura
En numerosas ocasiones pueden verse las tendencias de mercado en este ámbito. Sobresalen sistemas que permiten mitigar o detectar el riesgo de forma automática, evitando por tanto las temibles consecuencias de sufrir un ciberataque. Si bien estas herramientas permiten mejorar el estado de ciberseguridad, no solucionan los problemas de base. Además, introducen otros problemas adicionales derivados del mantenimiento de dichas soluciones (IAST o RASP).
Por tanto, para mitigar el problema, hay que ir a la raíz del mismo y realizar un cambio estratégico desde la base. Es importante pensar que la seguridad debería ser un elemento imprescindible desde el comienzo en cualquier proyecto de desarrollo y no solo la inclusión de un parche al final.
Para llevar a cabo este proceso es imprescindible convertir un SDLC (Software Development Life Cicle) en un SSDLC (Secure Software Development Life Cicle) Esto consiste en incluir aquellas tareas y procesos necesarios en cada una de las fases de desarrollo (siempre adaptado a la metodología de desarrollo elegida: Agile, Waterfall,…). En resumen, y de forma genérica, es imprescindible realizar las siguientes acciones y ubicarlas dentro de las fases del proyecto de desarrollo:
- Requisitos de seguridad. Es imprescindible asociar estos a la función y tipos de datos que albergará la aplicación en producción. Por tanto, dependiendo del grado de criticidad de ciberseguridad, los requisitos serán más simples o más complejos.
- Diseño seguro. La inclusión de los requisitos de seguridad en el diseño no puede hacerse de manera anárquica, debe respetar los principios de seguridad necesarios así como utilizar los componentes de software apropiados. Además, durante este proceso existen mecanismos que permiten realizar un análisis efectivo para comprobar que el nivel de seguridad de la aplicación será correcto una vez en producción, Threat Modelling.
- Desarrollo seguro. Una de las partes más importantes en cuanto a la seguridad. Es imprescindible que el concepto de desarrollo seguro abandere cada una de las líneas de código. Para abordarlo, la fórmula más adecuada es la formación en desarrollo seguro para cada uno de los miembros del equipo. Además, analizar el código para detectar cualquier desviación de riesgo es conveniente para confirmar la no inclusión de vulnerabilidades en el código una vez que esté ha sido integrado.
- En las fases finales, a parte de los procesos de testing habituales, realizar asssessments de seguridad para comprobar que la aplicación y todo lo que le rodea (sistemas, componente, comunicaciones…) es capaz de controlar y defenderse contra todos los casos de abuso identificados, ya sea técnicas de hacking o simplemente por fallos en la lógica de negocio.
Como resumen, es necesario cambiar la cultura en los proyectos de desarrollo. Evolucionar el modelo e involucrar a todos los miembros del equipo, ya que cada uno tiene su responsabilidad para asegurar el buen hacer de la aplicación en cuanto a seguridad una vez en producción. Para ello, es imprescindible la formación en desarrollo y diseño seguro para el equipo. Este cambio de cultura debe venir marcado y esponsorizado por la dirección del proyecto, que por tanto, debe dotarle de la importancia que se merece a la vista de los riesgos que se obtienen al no hacerlo.
