¿Qué es eso de S-SDLC?
S-SDLC es una metodología para el desarrollo de software, que hace hincapié en la seguridad en cada fase del ciclo de vida, desde el inicio, hasta el fin.
¿Qué beneficios aporta?
Aplicaciones más robustas, disminución de problemas en producción y ahorro en tiempo de desarrollo, ya que se construye con la seguridad en mente (sin olvidar la usabilidad o aspectos de rendimiento), los posibles bugs que se vayan introduciendo se detectaran en fases más tempranas, y por lo tanto los cambios para arreglarlo serán menores.
¿Qué tareas se incorporan?
En cada fase del ciclo de vida existirán unas tareas a realizar, se muestran en la siguiente imagen:
Ni que decir que la formación es un aspecto fundamental y es la clave para conseguir nuestras metas, si los arquitectos de software, desarrolladores, etc. no tienen nociones de seguridad, o cómo se aplica un requisito de seguridad (por ejemplo, ¿cómo hacer de manera segura una consulta a la base de datos desde Java?)… empezamos mal. También es importante contar con especialistas en seguridad que den soporte y resuelva dudas a lo largo del desarrollo, no hay olvidar que
Aunque aquí no se mencionen las metodologías ágiles, llevar a cabo estas técnicas, por ejemplo a Scrum, es muy fácil.
¿Cómo se puede llevar a cabo?
Voy a hablar desde mi experiencia. Partiremos de unas necesidades de negocio, es decir, qué quieren que se desarrolle, la funcionalidad que debe tener, etc. No me quiero enrollar mucho, así que vamos a ver directamente cada fase:
1. Análisis
Se tiene que tener en cuenta los requisitos que negocio pone, comprobar la normativa que puede afectar y obtener parte de nuestros requisitos de seguridad. Aquí definiremos unos mínimos de seguridad que nuestro software debería tener.
Se puede ayudar con un documento de preguntas predefinidas, por poner unos ejemplos:
- ¿Se van a procesar datos personales? GDPR entra en juego.
- ¿Se tratan tarjetas de crédito? PCI DSS es lo tuyo.
La salida de esta fase se irá al diseño, y en particular, nos vale para al desarrollo de nuestro modelado de amenazas.
2. Diseño
Durante el diseño, es necesario realizar conjuntamente un modelado de amenazas, existen diversas herramientas, entre las que destaco la de Microsot, herramienta gratuita e intuitiva de usar, otras a investigar: IriusRisk o OWASP Threat Dragon.
Me voy a centrar un poco más en esta fase, ¿en qué nos va a ayudar esto de modelar amenazas?
- Entender los requisitos de seguridad: al ir realizando el modelado de amenazas, irán surgiendo requisitos de seguridad, y podremos hacernos a la idea de que controles van a aplicar, teniendo en cuenta que algunos no se podrán llevar a cabo, ya porque no se alinean con negocio, ser muy costosos, etc. (no hay que olvidar llevar un registro y poner los motivos de porque no se aplican).
- Detectar defectos en fases tempranas: ayuda a identificar los posibles problemas antes del desarrollo, por lo tanto, hará a los desarrolladores “escapar” de los errores, y por lo tanto evitar la necesidad de cambios que puedan afectar otro código y hacernos perder tiempo. Lo que nos lleva al siguiente punto y al final lo que a todos interesa…
- Entregar mejores productos
¿Y qué vamos a hacer?
Teniendo en cuenta que el acceso no autorizado a los activos, principalmente para robar datos, es la razón por la cual surgen las amenazas, tendremos que identificar lo siguiente:
- Objetivos de seguridad
- Activos y dependencias externas
- Zonas de confianza
- Amenazas y vulnerabilidades
3. Desarrollo
Es muy recomendable contar con una herramienta SAST para que según se vaya desarrollando se puedan detectar posibles errores y arreglarlos antes de que sea demasiado tarde (no olvidar que estas herramientas nos pueden arrojar falsos positivos [entra en juego la revisión de código], por lo que contar con el experto en seguridad como se introdujo previamente, ayudaría a resolver dudas). En el siguiente enlace de OWASP se pueden encontrar herramientas, unas gratuitas y otras de pago.
4. Pruebas
Cuando se ha terminado el desarrollo, hay que comprobar que todos los requisitos de seguridad a aplicar, se han realizado correctamente.
Aquí es muy aconsejable, por no decir obligatorio, realizar un análisis estático, para que detecte posibles problemas que vengan del desarrollo. Algunos diréis, que pesado, ¡esto está repetido! Toda seguridad es poca ;).
Y ahora llega el turno de realizar el análisis dinámico (DAST) de la aplicación o sistema, que nos va a servir para encontrar vulnerabilidades mientras la aplicación está corriendo. Algún ejemplo de herramientas son Acunetix o Burp.
Os dejo un enlace en el que se evalúan herramientas: OWASP Benchmark.
5. Despliegue a producción
Bueno cuando llega el momento de estar en producción, llega nuestro queridísimo pentesting o pruebas de penetración con el fin de identificar posibles vulnerabilidades presentes en nuestra aplicación o sistema y ver si son explotables.
Una vez visto estos puntos, recordar que los entornos de desarrollo, pre y pro deben de estar aislados entre sí, pero que deben tener la misma configuración. Desde luego después de ver grandes empresas, a día de hoy es un reto, así que dejémoslo en “entornos lo más parecido posible”.
A continuación, dejo un par de capturas de un pequeño modelado de amenazas, con pocos componentes, para entender el concepto.
Esperemos que pronto todos los desarrollos incorporen la seguridad desde el minuto 1 del proyecto, ya que ganaremos todos. Hasta la próxima.
Entradas
muy buena información
ResponderEliminar