Hoy en día, la seguridad es uno de los temas más preocupantes en el sector de las tecnologías de la información. Esto se debe, principalmente, a la cantidad de datos sensibles que se comparte en Internet, así como a la velocidad con la que surgen nuevas tecnologías que dejan en entredicho sistemas de protección antiguos.
Tener en cuenta la seguridad durante todo el ciclo de vida del producto y no ignorar aspectos tan importantes como el diseño del nivel de seguridad o las infraestructuras que le dan soporte, son claves en el desarrollo de software.
Ciclo de vida y actores implicados
Actualmente, podemos encontrar una gran variedad de metodologías y entornos de trabajo que ayudan a la construcción de software (Waterfall, V-Model, Agile y Spiral Model, eentre otros). Es importante saber identificar cuál es el contexto del software que se va a desarrollar para elegir el mejor modelo de ciclo de vida a utilizar.
Sin embargo, pocas veces encontramos un capítulo dedicado en exclusiva a la seguridad en estos modelos. Podemos decir, por lo tanto, que la protección en el ciclo de vida del software siempre ha sido una tarea pendiente y que, muchas veces, se obvia por temas económicos o de planificación.
Tanto si nos fijamos en un método clásico y más utilizado como el ‘waterfall’, como si nos centramos en los métodos ágiles más modernos, podemos encontrar fases comunes que forman parte de cualquier desarrollo: definición, diseño, implementación, testing y evolución.
A esto se suma la importancia creciente del dato y la posibilidad de dotar a las máquinas de capacidad para tomar decisiones, que aumentan la relevancia de la seguridad. Hoy en día, podemos encontrar estándares (conjuntos de procesos y buenas prácticas que debemos seguir cuando desarrollamos software) y herramientas que nos ayudan a no perder de vista esta cuestión.
Por ejemplo, Microsoft lleva desde 2004 trabajando en un modelo integral que nos ayuda a mejorar las defensas en el ciclo de vida de nuestro proyecto (SDL).
Otro modelo muy extendido y recomendado por la OWASP (Open Web Application Security Project) es SAMM.
Del mismo modo, cada vez podemos encontrar más especializaciones en tareas que hace años carecían de importancia, por lo que se multiplica el número de actores involucrados, destacando el ’Champion Security’, que será el encargado de asegurar que se cumplen los estándares de seguridad dentro del software y diseñará el modelo de amenazas.
Importancia de la seguridad
Para ilustrar la importancia de esta área, es interesante el artículo del experto en ciberseguridad Daniel Miessler sobre los peligros de crear el software rápidamente, frente a desarrollos más largos, pero más seguros.
Afortunadamente, la tendencia está cambiando. La llegada del IoT y el Big Data hace que la preocupación a la hora de tener dispositivos inteligentes con capacidad para tomar decisiones aumente. Por eso, las grandes empresas invierten cada vez más en modelos enfocados a la seguridad y en perfiles específicos.
Si hablamos de IoT, la importancia de la protección cobra un especial protagonismo. En primer lugar, los dispositivos conectados no deben tener vulnerabilidades, ya que un atacante podría tener acceso a todo nuestro sistema a través de estos agujeros. Del mismo modo, hay dispositivos en los que entran en juego las vidas humanas, como los sensores que controlan un coche autónomo.
Marcos de trabajo en el ciclo de vida
Como se ha comentado anteriormente, existen modelos que nos facilitan estándares que podemos aplicar en el ciclo de vida del software.
SDL – Microsoft
Microsoft lleva años invirtiendo en la seguridad dentro del ciclo de vida del software. En 2004 sacó por primera vez este modelo público y gratuito.
Existen varias versiones que se pueden estudiar a la hora de integrarse en desarrollos más o menos grandes. En primer lugar, vamos a identificar el proceso que define Microsoft y que nos sugiere que tenemos que adoptar a la hora de construir nuestro software:
Las actividades en cada una de las fases son las siguientes:
- Facilitar training. Es importante que todos los participantes del proyecto conozcan el método, las fases y las actividades que cada uno debe llevar a cabo.
- Definir requerimientos de seguridad. Identificar cada una de las necesidades de seguridad que el producto necesita.
- Definir los índices que medirán la calidad de la seguridad.
- Usar un modelo de amenazas.
- Identificar los requerimientos de diseño.
- Definir la encriptación de los datos.
- Usar componentes de terceras partes seguros.
- Usar herramientas aprobadas y o certificadas.
- Realizar análisis de código estático.
- Realizar análisis de código dinámico.
- Realizar test de penetración
- Establecer un plan para responder a los posibles incidentes de la organización.
SAMM – OWASP
‘SAMM’ es un proyecto que pertenece a OWASP, una comunidad abierta cuyo objetivo es ayudar a las organizaciones en el desarrollo de aplicaciones seguras.
Una de las claves de ‘SAMM’ es proporcionar un modelo medible con diferentes niveles de madurez para que las organizaciones conozcan la seguridad de su modelo. Además, es agnóstico a la tecnología y la metodología de desarrollo.
‘SAMM’ define cinco áreas que se podrían relacionar con las clásicas fases del ciclo de vida del desarrollo, aunque no son las mismas.
Para cada área se plantean tres prácticas de seguridad, cada una de las cuales define una serie de actividades. En cada práctica, se definen dos grupos con objetivos definidos por el nivel de madurez.
A continuación, se muestra de manera esquemática cada uno de estos niveles, áreas y prácticas:
Como podemos observar, existen elementos comunes con el modelo de Microsoft, pero clasificados de manera diferente. También podemos ver que el modelo de amenazas es común en ambos esquemas.
Ninguno de los dos modelos comentados modifica las fases clásicas del ciclo de vida del desarrollo del software. Más bien se integran dentro de ellas para proporcionar unos procesos específicos que ayudan al aseguramiento de la calidad y la seguridad en el código.
Diseño de software seguro: el modelo de amenazas
Como se ha explicado anteriormente, los costes de abordar un problema de seguridad en las fases de definición y diseño son prácticamente nulos. Una de las actividades que más nos puede ayudar al diseño de software seguro es la utilización de un modelo de amenazas.
Se trata de un proceso en el que se pueden identificar los riesgos de seguridad y las acciones de mitigación que existen en los diferentes casos de uso o funcionalidades que definen un software. El propósito de esta herramienta es tener un análisis que nos indique los puntos en los que el sistema es más vulnerable, así como la manera de abordar dichas vulnerabilidades.
Existen multitud de herramientas que ayudan al diseño de un modelo de amenazas. Sin embargo, lo destacable en todos los modelos descritos es su carácter estricto en lo que a los procesos y las tareas definidas en cada uno de ellos se refiere. El objetivo es tener estrechamente vigiladas las amenazas y poder afrontarlas de manera efectiva.
El aspecto que tiene un modelo de amenazas es el de un flujo de información entre los diferentes componentes, tecnologías y actores que participan en el flujo.
Herramientas
También disponemos de herramientas que abordan los problemas de seguridad en otras fases del ciclo de vida del software, como la implementación o el testing.
Por ejemplo, las herramientas de análisis de código estático habitualmente eran procesos que se ejecutaban en back para todo el conjunto del código del proyecto. Sin embargo, hoy en día, podemos encontrar herramientas que se integran en los IDE’s de desarrollo, facilitando el análisis en tiempo real y agilizando, de esta manera la optimización, del código y el seguimiento de los estándares de calidad.
Actualmente, podemos encontrar gran variedad de herramientas de análisis de código estático. Entre las más utilizadas se encuentran: Sonarqube, Fortify o Raxis.
Otra etapa importante en la que es necesario apoyarnos en herramientas para facilitar la detección de vulnerabilidades,es la fase de testing, ya sea desde el punto de vista funcional o técnico. Este último punto dependerá de la plataforma tecnológica sobre la que se desarrolle el software, ya que no es lo mismo realizar testing sobre una web, que una aplicación stand-alone o un dispositivo IoT.