risque360 — Modelado STRIDE, Riesgo de Proveedores y Recalibración por Incidentes
Registro de riesgos unificado que reúne tres fuentes bajo un mismo motor de puntuación probabilidad × impacto: modelado STRIDE por componente de la aplicación, riesgo de proveedores puntuado con una heurística transparente y un registro de incidentes que propone recalibrar la probabilidad en 12 meses móviles — nunca aplicado sin validación explícita.
Contexto
Construí risque360 como complemento de mi registro risk-assessment-matrix (ISO/IEC 27005, EBIOS RM): un registro de riesgos clásico capta mal las amenazas propias de una arquitectura de aplicación, los riesgos que aportan los proveedores/terceros, y cómo un historial de incidentes debería modificar una probabilidad declarada «en frío». Reuní estos tres ángulos en un único registro, con un mecanismo de recalibración de probabilidad impulsado por datos — la parte más diferenciadora del proyecto.
Los 4 módulos
- Registro de riesgos organizacionales — mismo espíritu que risk-assessment-matrix (formulario manual, categorías de negocio)
- Modelado de amenazas de aplicación (STRIDE) — para un componente dado (API Gateway, servicio de autenticación, base de datos...), genera un riesgo por categoría STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
- Registro de riesgos de proveedores/terceros — un proveedor (nivel de acceso, estado del cuestionario de seguridad, incidente conocido) genera automáticamente un riesgo, con una probabilidad inicial estimada mediante una heurística transparente — nunca impuesta, siempre editable
- Registro de incidentes y recalibración — cada riesgo lleva una clave de correlación; los incidentes registrados bajo esa misma clave permiten calcular una probabilidad sugerida en una ventana móvil de 12 meses. La sugerencia nunca se aplica automáticamente — se requiere un botón «Aplicar» explícito
Algoritmo de recalibración
- 0-2 incidentes / 12 meses móviles
- Sin ajuste
- 3-5 incidentes
- Probabilidad +1 (tope 5)
- 6+ incidentes
- Probabilidad +2 (tope 5)
- Ejemplo validado por los tests
- «Phishing — robo de credenciales» (probabilidad declarada 2/5): 4 incidentes relacionados en 12 meses → sugerencia 3/5, mostrada con un botón «Aplicar» explícito
Heurística de proveedores (transparente, editable)
- Base
- Acceso alto: 3 · medio: 2 · bajo: 1
- +1
- Si el cuestionario de seguridad no se ha completado
- +1
- Si el cuestionario es conforme con reservas
- +1
- Si hubo un incidente conocido en los últimos 12 meses
- Tope
- 5
Error detectado y corregido durante el desarrollo
La generación automática de la clave de correlación (a partir del nombre de un proveedor o un componente STRIDE) no eliminaba la puntuación — por ejemplo, «PayGateway Inc.» generaba la clave fournisseur-paygateway-inc. con un punto final, lo que habría roto silenciosamente el enlace con los incidentes registrados bajo esa misma clave. Lo corregí con una función slugifier() compartida que elimina diacríticos y puntuación antes de generar la clave, y verifiqué la corrección con una prueba directa del módulo en aislamiento (importación con cache-busting) para descartar cualquier efecto de caché de módulos ES durante la depuración.
Resultados
- Stack
- HTML/CSS/JS vanilla (módulos ES, sin dependencias) + CLI Python (argparse, Jinja2, pytest)
- Tests
- 6 tests pytest — límites de nivel, heurística de proveedores, ventana de 12 meses, niveles de recalibración, no mutación de la vista previa, validación del conjunto de datos de ejemplo combinado
- Paridad JS ↔ Python
- Lógica de recalibración duplicada de forma idéntica en la CLI Python (recalibration.py), probada por separado
- Interfaz
- App con pestañas: Panel (mapa de calor + registro global), Registro, STRIDE, Proveedores, Incidentes