DevSecOps – Innovación y Seguridad de la mano

RESUMEN

La innovación y la seguridad deben funcionar de forma paralela, para permitirlo nace el DevSecOps. A día de hoy un 84% de los incidentes ocurren en la capa de aplicación, si una aplicación no ha llevado a cabo un adecuado DevSecOps, para detectar vulnerabilidades a lo largo del ciclo de desarrollo, se pueden producir serios problemas hasta en las empresas más pequeñas. Explicaré las principales acciones a realizar para mejorar la detección de vulnerabilidades en el software, y así poder ahorrarse sustos en el futuro.

¿Qué es el DevSecOps?

Actualmente es un término que está muy de moda tanto en Ciberseguridad como en el mundo del desarrollo, y se puede considerar el presente y futuro del desarrollo.  A modo resumen el DevSecOps o SecDevOps, en cada parte se le llame de una forma distinta, es añadirle la seguridad a todos los procesos del DevOps. Para quien no lo conozca, el DevOps es el conjunto de operaciones y prácticas que se llevan a cabo para mejorar la eficacia y calidad en el desarrollo.

Un aspecto importante del DevSecOps es que no solo es algo de lo que solo se encargan los equipos de seguridad, sino que es algo de todos, y es la tendencia que se está tratando de implementar. De esta forma se permite que la innovación y la seguridad puedan funcionar de forma paralela

En un principio se puede pensar que DevSecOps es solo orientado a código y desarrollo, pero nada más lejos de la realidad, es algo que debe involucrar a todos los equipos IT en una empresa. Un proceso DevSecOps involucra a todos los aspectos tecnológicos al desarrollo seguro de código, a la configuración segura de los contenedores, a la seguridad de la nube, al hardening del servidor utilizado, etc. 

Un concepto esencial en el DevSecOps es el denominado “Shift left”, que es el desplazar las pruebas de seguridad a la izquierda. permitiendo de esta forma la detección temprana de vulnerabilidad. Cuanto más tarde se detecten las vulnerabilidades, como es en el caso de una aplicación en producción, mayor será el coste tanto en tiempo como en dinero para resolver el problema de seguridad.

En resumen la seguridad debe ser algo continuo, no puede ser algo que solo se aplique al final del proceso cuando ya estas en producción. Anteriormente la tendencia era que la seguridad  solo era testeada en producción, al final del proceso, lo cual hacía que el coste cuando se detectaba algo fuera mayor, y además poder llegar a perder capacidad de detección.  En este artículo os explicaré por encima en qué consisten cada una de las áreas de DevSecOp, y luego en el futuro entraré en el detalle técnico de cada una de ellas.

Las distintas fases

La primera fase en los procesos de desarrollo, es la parte del diseño, y ya desde aquí se debe empezar a incorporar la seguridad.  Tener en cuenta los problemas de seguridad desde la etapa de diseño, puede ayudar al desarrollador a que tenga en cuenta determinados aspectos de seguridad a la hora de programar, y lo mismo con la configuración de los servidores. Se utiliza la técnica del Threat Modeling para poder detectar los problemas de seguridad desde la etapa de diseño, otra formas más de garantizar que la innovación y la seguridad puedan ir juntas.

La segunda fase es la de la programación, aquí el programador debe tener en cuenta los requisitos de seguridad especificados en la fase anterior, para evitar posibles. Por otra parte, el programador debe tener en cuenta todos los aspectos pertinentes del desarrollo seguro, como es el aplicar el estándar de OWASP. Durante la fase de programación, se debe testear la seguridad del nuevo desarrollo, utilizando técnicas como los análisis estáticos de código, para poder detectar vulnerabilidades en el código desde un inicio. 

Luego en la parte de testeo se ejecutan pruebas más orientados a los que es la parte dinámica, ejecutando pruebas de penetración. Se debe ejecutar las pruebas de penetración cada vez que el desarrollador realice una subida a PRE de una nueva funcionalidad, para poder realizar una pruebas más exhaustiva y detectar las vulnerabilidades tempranamente.  

Se debe tener en cuenta que en las pruebas estáticas de revisión de código, se detectan vulnerabilidades que en las pruebas dinámicas es más complicado y a la inversa. Por ejemplo, un problema de criptografía es más fácil de detectar mediante una revisión de código, pero un problema de lógica de negocio es más fácil mediante una prueba dinámica, por lo que ambas pruebas son necesarias. 

En todas las pruebas realizadas es recomendable realizar tanto una prueba manual como una automática. Las pruebas automáticas se deben integrar dentro pipeline para que se ejecuten conforme se va desarrollando código, de esta forma el desarrollador va teniendo la información de forma inmediata. Al final uno de los pilares fundamentales del DevSecOps es la automatización, ya que al final el objetivo último del DevSecOps es tratar de que la seguridad obstaculice lo menos posible a los tiempos de desarrollo, pero sin perder efectividad.

Por último tenemos la fase de subida a producción, aquí también se realiza un pentesting para tratar de realizar una detección de vulnerabilidades en un entorno real, sería lo que se considera “una prueba de fuego”. Es importante que se hayan realizado bien todas las acciones de detección y prevención previas, ya que las vulnerabilidades detectadas en esta fase tienen una mayor coste de tiempo a la hora de remediarlas.

Otro aspecto fundamental en la última fase, es el de implementar de forma adecuada la monitorización, como es por ejemplo realizando el registro en los logs, de todo lo que ocurre en el servidor. Esto es importante, debido a que a partir de los logs es como se detectan los posibles incidentes de seguridad, ayudándose de tecnologías SIEM para realizar el filtro por reglas.

Para concluir, en todos los procesos que se han explicado en este artículo hemos puesto como ejemplo el facilitar el desarrollo seguro mediante el DevSecOps, pero también se puede aplicar desde la misma forma a nivel de infraestructura o contenedores. El DevSecOps ha venido para quedarse y poder facilitar la integración en los actuales ciclos de desarrollo, y garantizar que la innovación y la seguridad puedan funcionar de forma paralela.

 

Alejandro Rueda Romero – Ingeniero en Ciberseguridad