«Application Security» con Microsoft SDL
El otro día estaba en una entrevista de trabajo en el que me preguntaban si tenía experiencia en metodologías de desarrollo seguro de software. Tras salir de allí pensé que nunca había escrito por aquí sobre ese tema y es algo que me costó encontrar cuando me quise enfrentar al reto de asimilarlo. Es por eso que os traigo la primera de varias entradas, ¡espero que os gusten!
Cuando trabajas como responsable de seguridad, participar en los procesos de desarrollo de software es una de las tareas en las que tienes que dar lo máximo.
Como es lógico, las aplicaciones estarán expuestas a todo tipo de usuario. Puede que sean para uso interno (limitando un poco la exposición) o pueden estar abiertas al mundo, pero siempre serán un objetivo para los fallos «espontáneos» o «buscados» de seguridad.
En la forma de trabajo que hemos tenido hasta «hace cuatro días», se desarrollaba siguiendo un modelo Waterfall, el que se daba (se sigue dando?) en la Universidad en la que todo tenía una secuencia inalterable basada en:
- Toma de requisitos
- Diseño
- Desarrollo
- Pruebas
- Mantenimiento (tras lanzamiento)
Todo muy encorsetado, siendo complicado arreglar ciertos problemas o añadir nuevos requisitos sobre la marcha. Es cierto que se logra una mejora al añadir la implementación de prototipos, lo que podría verse como un leve precursor del modelo agile.
En cualquier caso, utilizar este modelo ha llevado en muchas ocasiones a algo parecido al extreme programming donde se termina por lanzar a la papelera el diseño y los requisitos para realizar desarrollos inmersos en un éxtasis de locura, infinidad de horas y mucho café.
El problema de este tipo de forma de trabajar es que da lugar a todo tipo de fallos de seguridad, sobre todo en viejos modelos de pruebas de seguridad «binarios», lo que se traduce en «si da tiempo hago alguna prueba y si no…, pues no».
Como podrás entender, en un mundo en el que cada vez hay más tecnología, en el que todo está conectado y en el que los problemas de seguridad pueden arruinar literalmente negocios y grandes empresas, esa forma de desarrollar ya no es viable.
Microsoft y la seguridad
La multinacional de Redmond archiconocida por el sistema operativo Windows, desde hace años colabora de forma sistemática con gobiernos y organizaciones en la búsqueda de las mejores prácticas en materia de ciberseguridad.
Una muestra de esto es su definición del ciclo de vida de desarrollo seguro, más conocido como Microsoft SDL, que se estableció internamente para todos los desarrollos desde el año 2.004.
Como ejemplo, podemos ver cómo los productos Microsoft han mejorado sustancialmente con respecto a los fallos graves de seguridad detectados antes y después de la puesta en práctica del modelo.
Figura 1 – Boletines de seguridad importantes y críticos de Windows antes y después del SDL
Figura 2 – Boletines de seguridad de SQL Server 2000 antes y después del SDL
Figura 3 – Boletines de seguridad para Exchange Server 2000 antes y después del SDL
Introducción a Microsoft SDL
La metodología que nos presenta Microsoft SDL se basa en tres conceptos principales que tendremos que tener siempre en cuenta:
Formación: todos los roles tanto técnicos como de gestión dentro de un proyecto deben estar debidamente formados en seguridad. Puesto que cada día aparecen nuevas vulnerabilidades y nuevos ataques, la formación debe ser continua en el tiempo y de la mejor calidad posible.
Mejora continua: es importante comprender la causa y el efecto de cada vulnerabilidad para evaluar de forma periódica todos los procesos, así podremos implementar los cambios que sean necesarios.
Responsabilidad: será muy importante archivar toda la información necesaria para realizar el mantenimiento de una aplicación cuando aparezcan los problemas. Tener un plan de detección y respuesta ante incidentes de seguridad nos permitirá poner en movimiento a todas las partes implicadas en el mismo.
Es por eso que el modelo de Microsoft SDL se estructura en cinco áreas de capacidades alineadas con las fases clásicas de desarrollo de software:
- Formación, directivas y capacidades organizativas
- Requisitos y diseño
- Implementación
- Comprobación
- Lanzamiento y respuesta
Con el paso del tiempo y la creciente utilización de metodologías ágiles, Microsoft ha implementado una versión especial del SDL para este tipo de forma de desarrollar. Dicho modelo lo iremos viendo en las próximas entradas.
¿Te lo vas a perder?
Me especializo en la creación de arquitecturas en la nube seguras y escalables en entornos regulados (tecnología financiera, banca, salud, industria farmacéutica), combinando una profunda experiencia técnica con liderazgo estratégico.
Ámbito actual:
• Gestión de la seguridad en más de 40 cuentas de AWS en una configuración de múltiples cuentas.
• Dirección de la estrategia, la gobernanza y la arquitectura de seguridad en la nube.
• Impulso de prácticas de DevSecOps y seguridad desde el diseño.
Resultados demostrados:
• Reducción del riesgo de seguridad en un 40%.
• Optimización de los costes de la nube en un 15%.
• Superación con éxito de auditorías sin incidencias (PCI-DSS, SOC2, CSA).
Competencias principales:
• Seguridad de AWS (IAM, GuardDuty, Security Hub, Config, Inspector, Detective, Macie).
• Estrategia de cuentas múltiples, SCP y gobernanza a gran escala.
• Cumplimiento normativo y gestión de riesgos en entornos regulados.
Me gusta trabajar en la intersección entre la seguridad, la ingeniería y los negocios, ayudando a las organizaciones a crecer de forma segura sin frenar la innovación.
Anteriormente trabajé en Accenture (responsable de seguridad de AWS), liderando iniciativas de seguridad en la nube para clientes empresariales.
- Pathfinding Labs: el “parque de atracciones” en AWS Security - 19 mayo, 2026
- De una credencial olvidada al control total: cómo se materializan los ataques en cloud - 20 abril, 2025
- HIPAA: Protegiendo la Privacidad y Seguridad de la información médica con AWS - 13 septiembre, 2024
