La mayoría de los problemas de seguridad empiezan mucho antes del primer git init. Se deben a decisiones de arquitectura, suposiciones pasadas por alto y requisitos omitidos. La planificación es donde debería empezar el desarrollo seguro, no porque sea divertido, sino porque es barato. Detectar un modelo de autenticación roto en una sesión de pizarra es más rápido que parchear una brecha de producción dos sprints más tarde. Esta sección le muestra cómo diseñar con la seguridad en mente desde el principio. Aprenderás a ejecutar modelos de amenazas ligeros que no apestan, a escribir historias de usuario centradas en la seguridad y a clasificar datos como un profesional. Sin palabrería. Sin necesidad de un doctorado.

Imagen de marcador de posición: Descripción de la imagen: Flujo de la fase de diseño con iconos de modelado de amenazas, clasificación de datos y plantillas de historias de usuario seguras, superpuestos en un tablero de planificación de sprints.

Modelado ligero de amenazas para equipos de desarrollo: no es necesario un doctorado ni un taller de tres días

No hace falta pasarse días construyendo árboles de ataques ni organizar un taller de modelado de amenazas con 14 partes interesadas. Basta con detenerse y formular las preguntas adecuadas en el momento oportuno.

¿Qué puede salir mal?

Esta es la pregunta que importa. ¿Qué pasa si se filtra una ficha? ¿Si alguien manipula la entrada? ¿Si un usuario se salta un control del lado del cliente? Recorre los flujos básicos de tu función y hazles agujeros. No estás diseñando para usuarios ideales, sino para defenderte de abusos creativos. Incluso 10 minutos de "qué pasaría si" pueden detectar fallos lógicos, validaciones que faltan o límites de confianza obvios.

Ganancias rápidas: STRIDE-por-Función, Sesiones de Pizarra Blanca

No necesitas modelar toda tu aplicación. Basta con modelar con amenazas las cosas nuevas. Prueba STRIDE-por-característica. Tómate cinco minutos y pregúntate si la función introduce suplantación de identidad, manipulación, fugas de información, problemas de privilegios o denegación de servicio. O coge una pizarra y dibuja el flujo de datos. ¿Quién habla con qué? ¿Por dónde entra la información del usuario? ¿Dónde debe haber controles? Se sorprenderá de lo mucho que se descubre con sólo ir más despacio y trazar líneas.

Incorporación de la seguridad a las historias de usuario y los requisitos

La seguridad no puede vivir únicamente en los documentos de arquitectura o en el backlog del equipo de seguridad. Debe formar parte del flujo de trabajo de desarrollo, empezando por la forma de escribir las historias.

"Como usuario, quiero que mis datos estén...".

Las historias de usuario son un buen lugar para incorporar expectativas. No te limites a escribir "Como usuario, quiero restablecer mi contraseña". Prueba con "Como usuario, quiero que el restablecimiento de mi contraseña sea seguro y esté protegido contra la fuerza bruta". Esa frase desencadena discusiones sobre limitación de velocidad, caducidad de tokens y registro, antes de que se escriba el código. La seguridad debe formar parte de la definición de "hecho", no ser una ocurrencia tardía añadida al control de calidad.

Clasificación de datos: Saber qué necesita Fort Knox frente a un simple candado

No todos los datos son iguales. Algunos campos, como los nombres de usuario, son públicos. Otros, como los SSN o los tokens de autenticación, necesitan cifrado, control de acceso y un registro estricto. Durante la planificación, pregúntese: ¿qué datos estamos recopilando? ¿Dónde se almacenan? ¿Qué consecuencias tendría una filtración? Etiquételos en consecuencia. Esto le ayudará a diseñar protecciones acordes con el riesgo. Para empezar, no hace falta una estrategia completa de gobernanza de datos: basta con un poco de etiquetado y sentido común.

El desarrollo seguro no consiste en frenar la innovación. Se trata de hacer las preguntas correctas desde el principio, para no tener que arreglar las cosas difíciles más tarde. 

Pasemos a la fase de código y hablemos de cómo escribir lógica segura sin convertir cada pull request en un incidente de seguridad.