¿Qué es el ciclo de vida del desarrollo de software seguro (SDLC seguro)?

Ejemplos de iniciativas de seguridad del software

Antes de adentrarnos en la cuestión de cómo incorporar la seguridad en el propio SDLC, es importante entender los tipos de actividades que corresponden al ámbito de la «seguridad» en una organización de software. Veamos algunas prácticas que muchas organizaciones ya pueden estar implementando (o planeando hacerlo) de una forma u otra. El objetivo de esta lista no es enumerar todas y cada una de las iniciativas posibles, sino simplemente dar algunos ejemplos de actividades que pueden implementarse para mejorar la seguridad del software.

Análisis estático

El análisis estático consiste en analizar código fuente de forma automática con el objetivo de detectar defectos y vulnerabilidades. Se trata de un proceso normalmente automatizado que identifica patrones conocidos de código no seguro en un proyecto de software —como la infraestructura como código (IaC) o el código de una aplicación— y que da a los equipos de desarrollo la oportunidad de corregir los problemas mucho antes de que lleguen al usuario final.

Análisis de seguridad

De manera similar al análisis estático, el análisis de seguridad es un proceso que suele estar automatizado mediante el cual se analiza una aplicación completa y su infraestructura subyacente para identificar vulnerabilidades y errores de configuración. Hay diferentes formas de llevar a cabo este proceso, como los análisis de secuencias de comandos entre sitios, los análisis de puertos o la búsqueda de vulnerabilidades de los contenedores, por mencionar solo algunas opciones.

Revisiones del código

Aunque los análisis automatizados son útiles, siempre viene bien que una persona se encargue de hacer una segunda revisión y eche un vistazo al código antes de que este se publique en un entorno de producción. Si bien la mayoría de los equipos de desarrollo ya hacen revisiones del código para detectar defectos y otros errores lógicos, si se adopta el enfoque basado en la seguridad correcto, las revisiones del código también permiten identificar vulnerabilidades menos comunes para evitar que se introduzcan en la base de código.

Pruebas de penetración

Las pruebas de penetración son una práctica mucho más intensiva que requiere la contratación de un profesional de la ciberseguridad para que ponga a prueba la seguridad de la infraestructura de producción de una empresa. La persona encargada de realizar estas pruebas puede emplear diferentes métodos, desde un análisis de vulnerabilidades hasta la ejecución de un exploit real. Los resultados de este proceso se presentan en un informe en el que se detallan los distintos problemas que los controles de las pruebas de seguridad no han conseguido detectar.

Programas de Bug Bounty

Se trata de una actividad parecida a las pruebas de penetración, pero con algunas diferencias. El objetivo de los programas de Bug Bounty es que los usuarios informen de las vulnerabilidades que encuentran a cambio de una recompensa. Son una buena forma de incentivar a la gente para que informen de los problemas de seguridad con los que se topan, en lugar de explotarlos en beneficio propio.

Formación

No hay que subestimar nunca el potencial de un buen programa de formación. El mundo de la ciberseguridad cambia constantemente. Gran parte de los consejos y el conocimiento que eran útiles hace una década se han quedado obsoletos, y lo mismo pasará dentro de diez años con lo que sabemos en la actualidad. La formación en seguridad puede ser muy útil para mitigar las vulnerabilidades más comunes: aquellas cuyo origen son errores humanos.

El ciclo de vida del desarrollo de software (seguro)

El proceso de integración de la seguridad en el ciclo de vida del desarrollo de software debe parecerse más a entretejer los aspectos relacionados con la seguridad que a apilarlos uno detrás de otro. Es decir, en lugar de añadir una «fase de seguridad», estaríamos hablando de establecer un conjunto de prácticas recomendadas y herramientas que se puedan (y se deban) incluir en las fases del SDLC que ya existen. Ya sea mediante la implicación de las partes interesadas del equipo de seguridad, el uso de herramientas automatizadas o la promoción de iniciativas de formación, es imprescindible que la seguridad se aborde como una evolución del proceso y que no se trate como una mera casilla de una lista de comprobación. Solo así lograremos que la seguridad se integre de manera más sostenible y, lo que es más importante, que aporte un valor mayor.

1. Requisitos

   Durante la primera fase del SDLC, se debe definir claramente el problema, cuáles son los requisitos de seguridad, así como cuándo se puede considerar que una tarea se ha completado. Esta es la fase en la que todos los informes sobre errores, las solicitudes de funciones y las vulnerabilidades publicadas pasan de ser tickets a proyectos. En el caso del SDLC seguro, el reto principal es la priorización. Si involucra a miembros del equipo de seguridad durante el proceso de preparación, tendrá la garantía de que cuenta con el suficiente contexto para medir el impacto que tiene cada nueva función o corrección en el SDLC en términos de seguridad.

2. Planificación

   Una vez identificado el problema, es necesario dar con la solución. El equipo deberá decidir qué es lo que va a crear. Al igual que sucedía en la fase en la que se establecen los requisitos, el equipo de seguridad también debe participar en la fase de planificación, ya que puede aportar sugerencias y comentarios para asegurarse de que la solución elegida corrige el problema de una forma segura y que aporta valor al cliente.

3. Diseño

   Después de definir todos los requisitos de seguridad, es el momento de determinar cómo va a materializarse la solución elegida en la aplicación. Desde el punto de vista de la arquitectura de software, esto conlleva generalmente diseñar la solución de principio a fin. ¿Qué sistemas se verán afectados? ¿Qué servicios van a crearse o a modificarse? ¿Cómo interactuarán los usuarios con esta función? Además de contar con la revisión y la aprobación de otros miembros del equipo de ingeniería, la fase de diseño también debe pasar por una fase de revisión que corra a cargo del equipo de seguridad, para así identificar cualquier posible vulnerabilidad. Es fundamental que establezca una comunicación eficaz durante las tres primeras fases del proceso, ya que, de lo contrario, se arriesga a que los problemas de seguridad se identifiquen cuando el proceso ya esté demasiado avanzado.

4. Implementación

   Ahora es el momento de ponerse manos a la obra y de transformar el diseño en código. En esta fase, es también cuando entran en juego algunas de las prácticas de seguridad mencionadas más arriba. Por ejemplo, el análisis estático es una solución sencilla y económica que puede ejecutarse en cualquier confirmación o inserción y que brinda a los equipos de desarrollo comentarios prácticamente en tiempo casi real sobre el estado del código que están escribiendo.

   Una vez que el código esté listo y el proceso de revisión se haya iniciado, es necesario que un equipo bien formado revise el producto final con el objetivo de detectar errores lógicos y posibles problemas de seguridad. Al igual que ocurre con la calidad de los productos, la seguridad de una organización fuerte es responsabilidad de todos los miembros del equipo y no solo de los trabajadores que se encargan de la seguridad.

5. Pruebas e implementación

   Solo cuando el código se ha escrito y revisado, se puede pasar a la fase de pruebas reales y a su posterior publicación. En este punto del proceso, deberá recurrir a herramientas de análisis de seguridad más potentes que permitan analizar la seguridad de la aplicación de forma más exhaustiva. Dependiendo del tamaño de la función y de los recursos disponibles, también puede ser un buen momento para implementar pruebas de seguridad manuales. Al detectar vulnerabilidades mediante estos métodos, podrá implementar soluciones en las herramientas automatizadas existentes para protegerse de regresiones en el futuro.

6. Mantenimiento

   La publicación de código en entornos de producción no es algo de lo que podamos olvidarnos alegremente una vez hecho. Si desea que su código funcione en óptimas condiciones, deberá seguir prestándole atención y manteniéndolo, ya que es inevitable que los recursos cambien y se produzcan errores, y debe tener en cuenta que cada día se descubren nuevas vulnerabilidades. Aunque la fase de mantenimiento normalmente se destina a identificar y corregir los defectos en el código, también es el momento en el que se detectarán muchas vulnerabilidades.

   Es importante no engañarse a uno mismo y pensar que, si un código es seguro cuando se publica, seguirá siéndolo siempre. Desde los riesgos de la cadena de suministro hasta los exploits de día cero, el panorama de la seguridad cambia constantemente, por lo que es fundamental que establezca un proceso para identificar y responder a los problemas que vayan surgiendo cuando implemente un SDLC seguro.

7. Vuelta a la casilla de salida

   No olvide que el SDLC seguro es un ciclo y no un proceso lineal. Esto significa que, cuando llegue al final, deberá volver a empezar desde el principio. Cada error, mejora o vulnerabilidad que se haya identificado durante las fases de pruebas y mantenimiento dará lugar a una fase de requisitos individual. En la práctica, el desarrollo de software seguro es un ciclo ininterrumpido de mejora continua.

Conclusión: llegar aún más lejos

Aunque es probable que su organización ya esté poniendo en práctica alguno de los innumerables métodos que hay disponibles para integrar la seguridad en el SDLC, hay ciertas especificaciones asentadas que pueden ayudarle a llevar sus iniciativas de SDLC seguro a un nuevo nivel. Cuando empiece a integrar la seguridad en su propio proceso de desarrollo de software, le recomendamos que tome como referencia los recursos que indicamos a continuación, ya que pueden orientarle y servirle de inspiración.

Modelo SAMM de OWASP

El modelo Software Assurance Maturity Model (SAMM) de OWASP es la evolución del proceso Comprehensive, Lightweight Application Security Process (CLASP) de OWASP original. Se trata de un modelo consolidado que ofrece indicaciones claras para integrar las prácticas de seguridad en el proceso de desarrollo de software, haciendo hincapié en la importancia de adaptar las iniciativas de seguridad al perfil de riesgo adecuado para cada organización.

Marco SSDF del NIST

El marco Secure Software Development Framework (SSDF) del NIST es un conjunto de prácticas fundamentales de desarrollo de software seguro basadas en las prácticas recomendadas establecidas de organizaciones orientadas a la seguridad (como OWASP). Este marco divide el SDLC en las siguientes cuatro categorías, con las que se pretende mejorar la estrategia de seguridad del software de las organizaciones:

• Preparar la organización: asegúrese de que los trabajadores, los procesos y las tecnologías estén preparados para aplicar el desarrollo de software seguro tanto a nivel de la organización como a nivel individual en cada equipo o proyecto de desarrollo.
• Proteger el software: proteja todos los componentes del software de manipulaciones y accesos no autorizados.
• Producir software seguro: preste especial atención a la seguridad y produzca versiones del software con las mínimas vulnerabilidades de seguridad.
• Responder a las vulnerabilidades: identifique las vulnerabilidades que puedan haberse pasado por alto en las versiones del software y tome las medidas oportunas para abordarlas y evitar que se produzcan casos similares en el futuro.